Design UI component architecture

[pospi]

We need to sort out a best-practise approach for building isolated, reusable UI components. We should try to build 1 or 2 modules in a way that work for us and is easily extensible / customisable and then evaluate the ease of use.

There are some node modules that might be useful for this:

• https://www.npmjs.com/package/react-themeable
• http://postcss.org/

We want UI components to be entirely self-contained (like this). Tests, CSS, images and all other dependencies should be neatly bundled with each UI module, so that they can easily be exported for other applications without requiring the entire app repository to be imported as well.

We also want theming components to be simple, and completely restyling them to be possible as well. Creative use of CSS @imports is the preferred way of doing this, in preference to complicated and potentially flaky use of React's 'context' feature.

[bhaugen]

@ahdinosaur got time to kibitz on this? It's related to valueflo.ws .

[ahdinosaur]

hey, what do y'all need help with?

[bhaugen]

@pospi - @ahdinosaur is one of the value flows gang who is developing a React-based stack that might be somewhat similar to our goals here (I think - Mikey, let me know if I misunderstood). Here's that stack (I think): https://github.com/enspiral-root-systems/catstack

I thought it might be useful for @pospi @escanda and @ahdinosaur to compare notes a bit. Open-ended, I don't know if actual help is required, but I know Mikey (ahdinosaur) has worked through a lot of these issues.

And Mikey, this project is something like Value Flows in that it is converging three or maybe soon four forks of our NRP software, which was also one of the precursors to Value Flows. Processes of coming together. I don't know if it makes sense for all of these people to spend a lot of time conversing, but thought the gang here might want to know what your gang is doing over there, and maybe vice versa. If not, please forgive the interruption.

[pospi]

Thanks for the intro @bhaugen (:

@ahdinosaur - it looks like you've spent a lot of time and theory on getting as far as catstack. I notice a lot of the backing libraries are also your inventions.. so clearly it has been a long road getting to where you are now! Very keen to see if there are ways we can leverage what you've built to save ourselves some work.

It is very early days right now- I have just thrown together some info in the wiki to try to get some discussion started on what we want to achieve and how best to get there. I don't know how valid any of it is; I've done my share of React projects but am very new to OVNs and Python so it's hard to guage the validity of what I'm proposing there.

My first impressions glossing over the catstack work was that it was a little conceptually heavy, so might take us a while to understand it. I can possibly help to improve the docs once I've grokked things- I would prefer people are able to come into this project with basic understanding of React and be productive straight away without encountering too much 'scary stuff'. Your work might help us a lot- take a look over "Modular UI Components" on that wiki page and let me know if this is appropriate use of your toolkit or not (or if it solves other issues, let us know how they differ so we can incorporate those fixes into what we're doing as well).

Thanks!

[ghost]

I think I am all in with @pospi approach to self contained widgets. From the little React Native I know it follows that style, so if we are going to reuse components across platforms, I think that will be an important point. On the other hand we need some glue to manage state across the whole application. I like @ahdinosaur 's inu. Don't know though how it compares to Redux? It seems to me it has a smaller footprint but oth it may have less helper libraries.

[pospi]

I guess on that side of things I'd have to go with what is generally understood. I completely agree that streams are the future, but my concern is that building a stream-based backend for our app will make development inaccessible to newcomers- I've had this problem before with apps built using Rx.js. Conversely, most current-day React devs seem to find the Redux API intuitive enough. It might also depend a lot on the API architecture we choose- if we go the GraphQL route then Relay's HoC might be more appropriate.

In any case, we're kinda lumping two separate concerns together here. In this thread I was focusing specifically on the view layer, which I think is much more complicated in finding a workable solution. Data compartmentalisation & separation is much easier since all you really need to do is separate code into chunks, so I'll be pretty happy with whatever choice we end up making for that- Redux, inu, Relay etc all look pretty modular to me (:

[ahdinosaur]

hey sweet. i also do professional consulting work with React, Redux, React-Native, etc, so i can turn the dial on the spectrum of mad science to popular-choice architecture as you wish.

for theme-able styles in React, i've started recommending fela. for a more pure CSS approach to styles, i help maintain sheetify, where to theme you could use css variables.

for compartmentalizing all your view code into small modules, i use require in node or with browserify, which works great for either above style approach.

as for any other JavaScript opinions, sure i've got heaps (for example: i don't use most of fancy ES+), but i'll try and keep them to myself unless y'all ask. :cat:

[pospi]

Ok so I've gone down a path of trying to use the module import graph for as much of the setup as I can, which is an effort to get a 'friendlier' component dev setup online which still affords us the flexibility we want integrators to have later. Would be very interested to hear what the UI-component-abstraction thinkers in the channel have to say about some of the decisions if you have time to read it through (:

https://github.com/django-rea/rea-app/wiki/UI-Component-Architecture

[pospi]

For lack of opinions contrary to my own, marking this done!