How does this differ from a Redux-type store besides being able to instantiate them on demand instead of having a global state?
> It’s easy to screw up immutability in JavaScript, the actor internal state can be modified externally if users of the library are not extremely careful.
Sure, that's fine too. My point is more that it would've been nice to get a summary of the differences instead of requiring the reader to dig through the article, since Redux is much more prevalent. Even after digging, I still can't tell if there is a difference. If there is none, it would've helped greatly to explicitly say this.
The article is focused on explaining the design pattern, while Redux is influenced by the pattern.
From my understanding, Redux shares the actor/messaging pattern when dispatching events to the reducers, but the state in Redux tends to be centralized (you usually have one main store, but you can create other stores if you want), while in the Actor pattern, each object has it's own state.
Also, in Redux, information flows only in one direction: component => reducer => state. The Actor pattern seems to allow for actors to message each other back and forth.
Thanks for that explanation, that makes a lot of sense. See, if that had been included in the original article, I would've grasped it much more quickly, instead of being left wondering if Redux is implementing this pattern or I'm missing an obvious difference, and I'm sure it would've helped others too.
Actually it's quite opposite. Redux is a library which was created not until 2 years ago and it is used only in JavaScript. Actor model and similar message-passing patterns are in use for decades and not only in JavaScript but in many programming languages. They are popular e.g. in game development for communicating between game objects.
There is this weird viewpoint in JS community that world is turning around JS and its ecosystem, and this is the newest popular library that dictates standards rather than decades of CS knowledge ;)
Based on what shows up on the front page, I'd say the average reader is way more likely to be familiar with Redux than the actor model.
I never said Redux dictated the standard, I simply asked for the differences, and if it weren't for boobsbr's response, I'd be stuck in a state where I don't know how close Redux was to this model which is quite important to get context and understanding.
> There is this weird viewpoint in JS community that world is turning around JS and its ecosystem, and this is the newest popular library that dictates standards rather than decades of CS knowledge ;)
If you criticize people like this for not knowing what came first, then it's no wonder people feel like that because you'd never give them the opportunity to learn about the lineages. Instead, people will simply think "oh this looks like an interesting paradigm, maybe I'll consider using it in my next project" without realizing that they're already using it.
I'd also have liked to see destructuring used to set the new state:
return {
...state,
count,
}
I realize that it's superfluous when count is the only property on state, but it makes the code both easier to understand and to maintain as state gains new properties over time.
> It’s easy to screw up immutability in JavaScript, the actor internal state can be modified externally if users of the library are not extremely careful.
Object.freeze() can help prevent this.