Echo JS 0.11.0

Personally, I tend to prefer a feature oriented structure... where each feature is where directories are separated, and subdirectories created as necessary.

Each feature containing it's own context/state, components, tests and data fetching...  this can be registered with core routing and used in concert with more generalized components/wrappers.  It also tends to make it easier to break down into more of a micro-ui pattern if needed.

You can use redux-micro-frontend for state management in concert with exposing React and your UI component library of choice as global patterns from the start.  Again, easier to break things up later.

Just my own $.02

Not to be pedantic, but this isn't an implementation, it's a usage demonstration... an implementation would be a shim/shiv that adds it to String.prototype if it isn't present.

This is closer to where I'm coming from... when referencing articles, or interfaces, TS has pretty much become the more ubiquitous standard.  I'm fine with plain JS, but TS makes things a bit more clear in typical use... especially when explaining certain interfaces and libraries to make return types clear, etc.

Wonder if something like this could work with Microsoft's new Windows Terminal or Tabby.

I can't help but wonder, what is the overhead to manage such a beast across all the components used in an application using this approach.

While I know that it's not expressly required, but the article, and MobX itself would be easier to understand in the context if the code samples used TypeScript.

In some cases, it's less than clear with regards to usage.  Just my own $.02 ... I often prefer to use straight JS in practice, and sometimes find TS annoying, but it definitely helps in understanding, at least that's my take.

Anyone else have thoughts on this?

Note: you can self-host SuperTokens and the implementation appears to be floss.

For reference, the key doesn't need to be uuid/distinct globally... it *can* be, but whatever the natural key is for your iteration is generally fine.  Even if it's the text value itself, depending on the storage/persistence.

The reason for the key, is to minimize the DOM impact on large collections to only those nodes that have changed within whatever iterable/collection/array is used to populate the values.  Without such a key, a large (many hundreds to thousands) of DOM nodes/elements within that collection could be completely recomposed, which can be visually noticeable to jarring/jittery in terms of usage.

Not the Author... that said, one advantage of using a reducer to respond to events is that you can process your logic as a pure function which is easier to test both state and changes.  It also is better in terms of separating state management from render.

If course it's at the cost of a slightly more complex implementation and requires that separation of responsibilities in a clean way, which isn't always the case in practice.

It's part of why I've been such a fan of straight Redux for state management.  It's easier to compare/contrast with a state checker system such as the original Angular where projects and implementations have tended to have many bugs related to state management in practice.

Much like tdd, it doesn't make the code cleaner or better, but does make it more painful to not do it cleanly.

Dexie.js definitely looks interresting as a client side abstraction.

Not sure on the dexie cloud... pricing may be fine for some use cases, but could get expensive for popular hobby sites, and tend to prefer self-host options myself.  Relatively cool all the same.