5 ms·

How do you define "simple"? Simple is a very complex topic :) For example, in React the common way of using hooks is `useMyhook()` where "Myhook" is whatever y

How do you define "simple"? Simple is a very complex topic :) For example, in React the common way of using hooks is `useMyhook()` where "Myhook" is whatever you name it, like "useState", "useEffect", etc. So I'd argue that an API that follows the conventions in a platform is simpler than one that rewrites them. In this specific situation in the first demo, I would expect to have a hook called `useCounter()` instead of `counter.use()`. Furthermore, since we are manipulating state again the convention in React for state manipulation is to return the value and then the setter, like: const [counter, setCounter] = useCounter(); Now I understand since it's a global state we cannot give it a local initial value to avoid race conditions, so that's IMHO about as simple as you can get. I didn't do that, but I believe I got pretty close with my own React state management library https://statux.dev/ https://statux.dev/: const [counter, setCounter] = useStore("counter");

aenero 6y ago
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.
runawaybottle 6y ago
Hey, I like your version too. I’m digging these simple state libraries. Really proves just how absurd Redux was when you finally see the simple solution.
- franciscop 6y ago
  I believe Redux is good when you have 3+ people working on the same project front-end, and absolutely necessary when you have 10+. This makes it work great with the Facebook, Airbnb, etc. of the world. Which is totally fine, but not your everyday problem for the rest of us! I'm very happy to see all of these versions pop up as well.
  - runawaybottle 6y ago
    What makes that objectively true? I’m looking at these APIs, and at least two of these solutions are plain better design. What about this would get worse with more engineers or higher caliber engineers that Redux clearly avoids?
    - franciscop 6y ago
      It formalizes how data is created, accessed and modified. Instead of multiple places trying to modify some specific data ad-hoc and with possible collisions/changes, now you have a mores strict way of dealing with data. Basically the Flux architecture. See from 10:20: https://www.youtube.com/watch?v=nYkdrAPrdcw https://www.youtube.com/watch?v=nYkdrAPrdcw
      - aenero 6y ago
        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.

aenero 6y ago

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.

runawaybottle 6y ago

Hey, I like your version too. I’m digging these simple state libraries. Really proves just how absurd Redux was when you finally see the simple solution.

franciscop 6y ago
I believe Redux is good when you have 3+ people working on the same project front-end, and absolutely necessary when you have 10+. This makes it work great with the Facebook, Airbnb, etc. of the world. Which is totally fine, but not your everyday problem for the rest of us! I'm very happy to see all of these versions pop up as well.
- runawaybottle 6y ago
  What makes that objectively true? I’m looking at these APIs, and at least two of these solutions are plain better design. What about this would get worse with more engineers or higher caliber engineers that Redux clearly avoids?
  - franciscop 6y ago
    It formalizes how data is created, accessed and modified. Instead of multiple places trying to modify some specific data ad-hoc and with possible collisions/changes, now you have a mores strict way of dealing with data. Basically the Flux architecture. See from 10:20: https://www.youtube.com/watch?v=nYkdrAPrdcw https://www.youtube.com/watch?v=nYkdrAPrdcw
    - aenero 6y ago
      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.