fritzpassow

I think I understand the pieces now... React Functional Components: Are the preferred kind of component we write in React-Redux Are functions that take a "props" object Are the preferred way to output visual stuff and wire up events The Redux Store: Has all the state which we can display Has the dispatch(action) method, which is the only way to change state Your Mission (should you choose to accept it): Use the state and the dispactch(action) function Create props which are data values needed by the functional component Create props which are event handlers that call dispatch(action) The Locations: mapStateToProps : Here you get the state and return props which are just data mapDispatchToProps : Here you get the dispatch function and return props which call it And then React-Redux's "connect" function magically combines the mapping functions and your functional component into a new component which you elsewhere. ---------------------

With just callbacks or promises, one can almost read the code as non-functional, with a few extra parens 'n things thrown in. If you ignore the yellow parts below, it could almost be C or Java. whatever.then (()=> {       code       code       code } ) "then"... the code in curly braces happens. But in Redux, we get things like this fragment from  https://github.com/reduxjs/redux/blob/master/examples/todos/src/containers/VisibleTodoList.js const mapDispatchToProps = dispatch => ({   toggleTodo: id => dispatch(toggleTodo(id)) }) export default connect(   mapStateToProps,   mapDispatchToProps )(TodoList) Here,  mapDispatchToProps is a function which takes a function ( dispatch ) as its argument and returns an object who's property's value is also a function. Then  mapDispatchToProps  i s used as an argument to the connect(..) function which returns a function whose argument is  TodoList , a component which is also a function. S

Random thoughts while learning redux.... (Subject to later revision.) 1. Redux is Small Seriously. Go look:   https://github.com/reduxjs/redux/tree/master/src 2. Are Reducers the new Controllers? "Actions" mostly seem to be generated from the UI, or from very close to it with very little logic in between. The "Store" is just data. Period. So what's left is the Reducer. And it starts from where the controller would start. It might be worth pulling out business logic into some explicitly separated part. And that part could be all functional and testable, which seems like a good thing. 3. Object Model? My OO Java brain likes the idea of an object model that understands the things you want to do and offers methods for doing them. But the Store is data-only. And it's supposed to look like a bunch of relational tables interlinked by ID values. So it doesn't seem to be acting like an Object  model. ....But I really don't want to do ORM b

When I started learning Redux, I thought I had to clone my whole state tree before changing it in my reducer function. But this is not true (and is bad for performance). But I wasn't sure how to reuse parts of the old state without "mutating". After learning more, I think I see a practical version of the "don't mutate" rule which is: The Rule: Code that starts with a reference to the old state object can never be allowed to see any changes. Therefore, if you will change something somewhere out on a branch of the state tree, all of the change's parent objects must be new.  (So, the root of the new state tree is always a new object.) But, branches without changes can be reused .  Because code starting from the old root can safely traverse onto those branches because they contain nothing new. And the above also means that children of a changed node can be reused, as long as those branches have no other change. Of course, this all depends on y

I'm an old Java programmer. If I see x.foo and x.setFoo(y), then I expect x's new foo to be y. So in my linguistic world, Component.setState(x) really does an "updateState", or something, and it would have saved me some time if they had used a different name.  :-) Now I understand that the argument is really more like a delta. It only specifies that parts that are different. Also React starts with a shallow  comparison between the existing state and the argument to setState(...). So, if I don't compose setState's argument correctly, there can still be differences that React  will not find . I need to dig into this more. However, I'm learning Redux now, which does it's own setState(...), so I might not get back to this for awhile.

Given an element with two classes, i.e. class="foo bar" Select elements that have BOTH classes as .foo.bar {....}