Making RealWorld “realer” (2.0?)

This past year I’ve been trying out lots of different front end libraries, and was very happy to discover this project and the community around it.

I’ve been thinking about posting this comment for a while, as I’ve noticed these libraries have a fundamental design difference that RealWorld in its current form doesn’t account for: modularity and reuse.

It seems front end libraries fall into two categories - they either support some kind of architecture for modular reuse (often a stateful component concept) or they don’t.

The Conduit front end, per the current spec, does not present any use-case for any kind of UI control with any internal/accidental state - and while that may be realistic for some simple apps, in my experience, it isn’t enough for larger, more complex apps.

Almost every real-world (duh) app features some kind of recurring UI control that has some kind of state that’s only relevant while the control is on-screen.

Let me give a couple of examples to clarify what I’m talking about.

My favorite example is a drop-down date-picker. It has the selected date state, which is relevant to the application, and therefore typically bound to the application state rather than stored internally in the control instance. But it also has state indicating whether the control is currently open, which month is currently showing, and so on - I refer to this state as accidental, because it is typically of no relevance to the application, and it’s only relevant while the control is visible.

Another example is an auto-complete input. It has the selected value, which is relevant to the application. But also may have an XHR instance, a list of values, the current cursor position in the list, and so on - all of which are accidental, irrelevant to the application, and relevant only while it’s displayed.

It’s not that these kinds of controls can’t be implemented with stateless components/views, they can of course - but the application will need to maintain all this irrelevant state somewhere, and will need to manually keep track of visible controls etc. so that, for example, switching to a different tab in the UI correctly clears the state of, say, a date-picker that is currently open, since the user would likely find it confusing to return to a previous tab and find a date-picker (that they didn’t just click on) already open.

Implementing all this state management and wiring can sometimes be difficult in front-end libraries that don’t provide any kind of concept for modular reuse - sometimes near impossible.

Almost every major React, Vue or Angular project uses either third-party or first-party components/controls that have accidental state, so it seems pretty relevant, I think.

Something to think about for v2.0 maybe?