Defining architectural requirements for ValueFlows UI project
Hey all (and to some old & new faces who might be interested) - as roadmaps within and beyond our ecosystems continue to mature, it seems we are at a point where we can start building a truly portable user interface framework for rapid iteration of techno-social systems.
I'd like to use this thread to formalise precisely what this means in terms of ValueFlows-compatible user interface frameworks. There are things we could do in other areas (eg. aligning patchql with Humm's record schema); but for resource coordination problems I think I'm preaching to the choir here when I say that ValueFlows can unlock a lot of possibilities.
Beyond portability, modularity and extensibility a lot of effort also needs to go in to developer ease-of-use, because we want contributing to the project at any level to be as accessible as possible.
So this is just some thoughts and links to get the discussion started, I'd really love to iterate this with your help and see where we can combine forces to reduce overhead and co-enable each other as we progress (:
- GraphQL spec ensures that implementations are aligned and provides validation methods to verify compliance. This decouples UI components from depending on a particular backend.
- Graph federation helpers allow us to compose multiple schemas together declaratively into a single merged API. This decouples the UI components completely from the data sources, even when mixing multiple backends (eg. Scuttlebutt + HoloREA) within the same app.
- We should aim to deliver our UI components as pure WebComponents. Browser support for these is now mature and they enable portability between all possible UI frameworks (eg. React, Angular, Polymer, ...)
- Component wrappers for particular runtimes will have to be delivered in addition to the raw WebComponents (eg. for React).
- We should generate these as part of the build / publish process and deploy different packages for use with different libraries.
- We should use Svelte to develop the components themselves. It's extremely simple and accessible, I gave it to a junior dev & complete novice once and they managed to build a quite nice website (and have fun doing it!)
- We need to proof getting Storybook working with it
- We need to proof exporting both TypeScript and FlowType type definitions from the components to enable compatibility with both mainstream JS preprocessors commonly used in UI projects. Flow is much less restrictive than TypeScript, so perhaps using TS and generating flow from TS definitions is the appropriate direction to convert in. Also, Svelte uses TypeScript by default.
- svelte-apollo is already done so is svelte-redux-connect, so I think all the bindings we need for state management and API requests are already good to go.
- There cannot be any global styles whatsoever in the framework as this breaks predictability when importing in to existing web apps which have their own style globals.
- If we keep our data layer cleanly separated from our view layer, we can build equivalent React Native views for every web view and enable the frontend logic (excluding routing) to be shared between platforms.
- Apollo GraphQL works both in web & Electron environments as well as React Native.
- Must support serverside rendering for pre-render and no-JS environments. For Svelte we need to proof use of Sapper.
- We should make UI components white-label-able and customisable at as many levels as possible. Minimum requirements are to support:
- simple re-theming via customisation of global theme variables
- deep visual customisation via an accessible style framework
- ability to inject custom theme styles to entirely change visual appearance and only use the component's logic
- I have no real strong opinions on the CSS preprocessor we do or don't use unless others do; but we should probably sign off on something so I nominate SCSS. What are the cool kids doing these days?
- Style framework will probably have a similar architecture to rea-app, in that CSS framework mixins and variables are used to share common style elements between locally-scoped component styles. Note that this configuration impacts the repository layout and build system and will require enforcing some directory and file naming conventions. Using a templating framework to automate creating new components is probably a good idea.