My personal thoughts about that if you don't violate "Single Responsibility" principle it is perfectly fine to use one store

For things you describe at items such as swords, potions, helmets as well as NPCs I would not consider them as Stores I guess I would implement them as models. I, personally, use Stores as a way to collect some state outside of React's Component tree. I can have Store which has observable attributes which hold a list of Models, inventory for example and so on. What about Combining stores it really depends on what you want to achieve. If you need to do something as a result of something has happened on one store, for example, a user has moved and Position store changed coordinates and you may have some other store which should react to this changes in some way and may use reactions for this case. Another case might be that you just need to recompute something because some Store's value you depend on in some distant store has changed and you need to have different values now you might consider to use plain computed properties If I didn't answer your question please post some real case scenario you want to implement and maybe I can help you with that.

could you suggest a good book which describe theory behind it ? and one more question. what this translation NFA to DFA important in a first place? what the point of doing that ?

What programming languages, paradigms or ideas have influenced you to create Cycle.js? How your conceptual thinking shifted from where you've been to where you know? where it was (conceptual thinking) and where it know and path which you've went through?

Thank you. :)

Thank you. Definitely, solid advice :)

Hello Andrew. How would you recommend to learn Redux for someone who has small amount of experience in Functional Programming? I comfortable with React and now I want to use Redux with it, because approach I currently apply uses events to notify React components when my models have changed, kinda like Pub/Sub bus. What I've noticed this approach doesn't scale very well and it's hard to reason about code when code base becomes bigger. I've read few articles about Redux and I think it can help me. I have a lot of experience with OOP code. I worked with Ruby/Rails and focused a lot on good object oriented design. I don't have a lot of experience with functional programming in general. I have some experience with Scheme, mostly for learning recursion. I kinda understand lambda calculus and ideas behind it, I even wrote Applicative Y-Combinator using things like Tennent's Correspondence Principle and so on. Also I have some experience with Haskell. I know what "Currying" and "Partially applied function" concepts mean and what they for. For me it looks like that Redux is heavily based on ideas from Functional Programming. I think my question consists from 2 parts: What learning path would you recommend in order to be comfortable with ideas on which Redux based on? What knowledge/skills should I have in order to be really comfortable working with Redux and build applications using it? I know I wrote a lot here, but I think it will help you give me more specific advice using provided information. If you thinking that there is some programming language where some particular ideas expressed better, feel free to mention it. I've found that sometimes it's very beneficial to get to roots of some idea (yes, I do have a lot of free time). For example learning Smalltalk made me a better Ruby developer and OO developer in general. Thank you a lot for any suggestion/advice :-)

Hi Andrew. I'm going to start using Redux with React and in the process I want to understand how React/Redux and ideas from functional programming fit together. Would it be better to work with Elm first and then after I've understand big picture shifted back to React/Redux?