aenero

These have been implemented starting in version 0.1.0.

Based on feedback I got here so far, I'm working on a version that will add these functionality:

(1) helpers to generate base colors and palettes based on various color relationships, e.g. complementary, split-complementary, double-complementary, analogous, triadic

(2) auto-generating a complete set of palettes and their base colors (opinionated), based on a single color value input (the "primary brand color")

(3) opinionated default "role mapping function"

All the above provide various levels of "automation", from fully customized to single color value input, full automation.

Thanks for the feedback. Hope to get more of your valuable inputs.

Nice one indeed. Thanks for this.

I am gathering useful links like this, and will make them available in the README for further readings.

Great insights there.

Thanks for your feedback. I will copy+paste below my response to a similar feedback to my post.

--- start excerpt ---

The main intention/purpose of the library is to provide a well-defined structure to guide the developer in crafting their color system. Especially when using TypeScript, this benefit is immediately felt.

Since this is the very first release of the lib, it only includes this core functionality. Based on feedback from users, I intend to build up the library to include more things that users would say are useful to them.

Based on your comment, it looks like one such enhancement could be to add functionality to generate additional base colors based on a single "seed" color (e.g. the main brand color), e.g. a triad of base colors (primary, secondary, tertiary) based on Triadic Palette from the primary's base.

This is where feedback like yours will help make this library more helpful to more developers.

--- end excerpt ---

To address your specific example, the pattern you pointed out is not really equivalent to c(a, b). The color mapping function "c" is applied internally when building the individual palettes, not to (a, b).

I will try to make my example in the README a little less contrived, as I can see where the confusion is coming from.

Also when in the future versions this library will bundle various color mapping functions (again, based on user feedback), the structure provided by the library will make more sense because the "c" part there would be any one of the pre-built functions that you can just pass to the `colorScheme()` helper.

Again I appreciate your insights.

Thanks for your feedback.

The main intention/purpose of the library is to provide a well-defined structure to guide the developer in crafting their color system. Especially when using TypeScript, this benefit is immediately felt.

Since this is the very first release of the lib, it only includes this core functionality. Based on feedback from users, I intend to build up the library to include more things that users would say are useful to them.

Based on your comment, it looks like one such enhancement could be to add functionality to generate additional base colors based on a single "seed" color (e.g. the main brand color), e.g. a triad of base colors (primary, secondary, tertiary) based on Triadic Palette from the primary's base.

This is where feedback like yours will help make this library more helpful to more developers.

Thanks for pointing this out.

Admittedly a lot of pointers like this are missing in the README, because there's just a lot about Color Theory and generally the science behind color, than what my documentation has space for.

Can you recommend a link to a nice website where users can learn more about things like this? I would like to add that link to the README.

I appreciate your insights.

Thanks for your feedback.

This area is where TypeScript would play nicely. The library implements types that fully utilize generics to define and impose restrictions for color keys, as well as ensuring type consistency across the color system. * This is the next item in my list to add to the documentation. *

So for example, you can easily implement a color system similar to Material Design 3 that only accepts these color keys: 0 | 10 | 20 | 30 ... 90 | 95 | 98 | 100. But as this is not every color system's approach, the library adopts the least restrictive default, so you can say it's less opinionated.

But for pure JS projects, custom color mapping can do the job if your design system prescribes discrete color keys for palette colors.

Fair point. Thanks for pointing that out. Will update the README.

Hi. Thanks for your comment. This library provides the foundation for crafting any sort of color system. The choice of whether your color system's palettes should consist of complementary vs. analogous vs. other relationships of colors is entirely up to you, and the library makes it easy for you to systematically define that in code (by creating a custom "color mapping function", which is discussed in the README).

Although the library is not a color generator per se, it has one built-in palette generator (color mapping function), which is tonal/monochromatic--chosen as default because it's the most common palette type used by popular design systems like Material Design. You can use third-party libraries to aid writing any additional color mapping function you want to implement. (I can also include additional color mappings based on feedback.)

Ultimately, what simpler-color provides is a well-defined structure for your custom color system that works well with various color-generator libraries.

Glad you find it useful. And do let me know if you have suggestions on how to further improve its functionality. I've been using it on personal projects for a while now, but just published it recently. User feedback is definitely most welcome.

Hi! Just to quickly introduce a library that I recently published...

Using a proper color system for your UI ensures a cohesive, more polished look for your application. This library makes it super easy for you to create your very own color system.

Works both in browser and Node, and whichever UI framework/libraries you're using.

Hope you find this useful.

SimpleR State acts as a "module-level store", one of the reasons why it's so simple. When you start doing SSR, though, as with anything else in React global state management, you would sacrifice some of that simplicity.

So to answer the question, yes SimpleR State works with SSR, but you need to take an extra step. You would need to somehow "scope" your global state inside the React component tree. The most common solution is using a Context to store your server-side entities, so that they are not "shared" among SSR requests.

SimpleR State proclaims itself as "unopinionated", so the preferred SSR solution is a decision that the developer has to make. It would be worth adding some options in the documentation, though. So thanks for bringing this up. I also received a few requests on such documentation in the previous Request For Comments during the beta run. A doc page on SSR is underway.

Happy to hint that there is an upcoming plug-in to support Redux DevTools too. Soon.

Yes, I called it "transform function" in the documentation to reflect the more general functionality that also includes computed values, apart from selection ("picking" properties).

Thanks for your encouraging feedback.

Although this is not provided by SimpleR State out of the box, the library makes it easy to implement a "selector" function that accepts an SQL query, and pass this selector to the entity hook. This SQL query syntax in React can well be a library on its own, I suppose.

Happy to say that this also works well with TypeScript with minimal explicit types required. My main goal is to maximize the use of type inference. The documentation provides TypeScript version of each example (outside of the TL;DR cheat sheet), except in cases where TS version is the same as the JS due to type inference. Even where there is TS version, the difference from JS is minimal.

It would be counter-intuitive if I endorse a Recoil-based solution on this thread that talks about a different library, LOL.

But since I want to help as much as I can, my advice is, regardless of which library you choose, or which approach (atomic vs. monolithic/structured)... start with analyzing which parts of the state in your app really are supposed to be "shared" state. I have a feeling you may be trying to use "shared" state libraries to manage state that only the individual components would actually need. Do those dynamic components actually need to share data? The answer to that is the first important consideration, IMHO, before you can go forward.

Good luck.

Hi. There are LOTS of much more popular libs you can choose from. My library does not intend to compete as the "best" library, but it has a very specific set of goals, the topmost of which is simplicity through a minimalist API.

Don't get me wrong. SimpleR State is a "complete" library despite the simple API. It supports things like selectors, async actions, and plug-ins. And soon, it will come with built-in plug-ins like persistence, Dev Tools, validation, etc.

Everyone has different priorities when choosing a library, so I suggest going through the design goals that I highlighted in the README file, or complete documentation here:

https://simpler-state.js.org

and see if it fits what you're specifically looking for in a library.

At the end of the day, all these libraries are just React code. In that sense they differ in terms of patterns/principles behind their implementation, but maybe more importantly, in the API/syntax (which is what immediately matters to the developer using it). This is what I can confidently say that SimpleR State delivers... one of the simplest APIs you can find.

Hi. SimpleR State makes use of selectors without creating a new entity (unlike atoms in Recoil, for example). It uses the more classic paradigm used by popular libs like React Redux where you just use selectors to filter/transform the "received" state to the format required by the component, and not to "create" a derived state per se. I hope it makes sense.

Depending on which principles/patterns you are applying, you can go as elaborate as using something like Recoil for that (I think this might be a great application of Recoil as it deals with atomic data), or you can choose to go simple with a tree-type data structure that parallels your component tree.

But first thing you should identify, IMHO, is which of those states are _really_ "shared" states. Coz some of those state values are probably better kept local.

Actually I was favoring the official React Redux stuff in my comment. Just trying to balance it out by mentioning that Rematch, Easy-Peasy and other libraries in the ecosystem all have their own place in the open source world, even if they can be considered different flavor icings on top of the same cake.

Yup agreed. That's why I stated it as "I found it to be...", coz I'm not trying to convince everyone else LOL.

It's never my intention for this library to try and be the "best" out there. I simply want to create what I sought for, which is the closest to the simplest approach I can think of. And to share it to the public, in case someone out there is looking for the same thing I am, and maybe it could help that someone. That's what open source is for, after all.

I see what you're saying here, and actually agree at some level.

But there is always an alternative, IMHO. If the project has a good code structure and follow equally good coding standards and review process, using simple un-opinionated/flexible libraries would not be a liability with "scale" (in terms of team/project size).

And there's one advantage of simpler approaches for growing teams: faster/easier onboarding. Let's face it, even good React/Redux developers can understand simpler code faster.

Just an alternative thought. But I completely get your point.

Maybe "encapsulated" is not the right term when I simply meant "scoped".

I tried scoping the entities using Context in some prior art which we use in production. Some colleagues kindly gave me some benchmark results and the version without Context (external/module-scope) was faster.

I'm not trying to debate against Context here. In fact, there's nothing that would stop anyone from using SimpleR State's entities with Context API.

For folks who use Redux, the React Redux library has gotten much much more developer-friendly than it originally was. The other libraries like Easy Peasy and Rematch serve a nice syntactic sugar, though.

Following React conventions is certainly an option and is supported by SimpleR State's unopinionated and flexible syntax.

1. It was inadvertently removed from the documentation, but these are equivalent:

   const count = counter.use()

   const count = useEntity(counter)

but the `counter.use()` was chosen in the documentation due to more feedback that requested this "simpler" format (i.e. no need to import `useEntity()`. But again, to your point I will restore the mention of `useEntity` in the documentation.

2. As for the [state, setState] convention, think of useEntity more like useContext than useState. Then it gets simpler.

3. I would also argue that since this is "shared" state, the developer might (again, the library is not opinionated on this) choose to separate the logic of updating shared state. For this reason, I didn't see any reason to provide a setter through the hook, when you can access the setter from anywhere via something like counter.set(). Conforming to useState convention was not justified in this case, especially since useContext convention equally makes sense for shared state.

4. To suit whatever convention, you can always do something like this alongside the definition of the entity:

   export const useCounter = counter.use

I want to point out that SimpleR State provides the flexible constructs to allow the developer to tailor it to their preferred convention.

Thanks for your feedback.

With this one, you can write granular shared states (multiple "entities") without creating layers and layers of Context Providers in your component tree.

Since data is not encapsulated inside React component tree, I found it to be multiple times faster than when using Context.

And one thing that's perhaps the most obvious... it's simpler because you don't have to use Providers at all.

The optimizations on preventing unnecessary re-renders are well-documented here:

https://simpler-state.js.org/recipe-transforms.html

Thanks for your reply.

You'd be happy to know those are supported and documented at https://simpler-state.js.org

Specifically, look at these "Recipes" pages:

https://simpler-state.js.org/recipe-async.html

https://simpler-state.js.org/recipe-orchestrators.html