MDN has a very good page on async (and await ) . Having read them the MDN page plus a bunch of other tutorials, here are my key takeaways: In general: async and await are just a nicer syntax for working with promises. So learn promises. Understand promises. And then use async and await to make your promise-using code look nicer. About async : Putting async in front of a function definition allows you to use await inside that function. Putting async in front of a function definition also wraps the function's return value in a promise, if the return value wasn't a promise already. So if my function gets data via a promise and then extracts and transforms the data before returning it, I can just return my transformed data and let async magically re-promise-ify the data for me. :-) About await : await lets me use functions that return promises, but write code that looks synchronous, i.e.the code looks as if the function that returns a promise was an old fa...
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. ---------------------...
Just putting this here so I will see it next time I need it... If I've been fighting with a bug, or a new technology that just isn't working for me, I eventually lose energy. A solution that has worked for me is to find a way to write more working code , while still staying somewhat close to the problem. For example: Write "toy" code that uses the new tech I'm stuck on. Write, and test, a wrapper for something I've partially learned which is still being troublesome in my project. Review existing code and rewrite it with a cleaner design Write more tests The point is to write more working code, any way you can . Successful coding is fun and makes our brains happy. We get discouraged when we are not writing working code. So the trick is to find some place close to the problem where we can write working code, and write working code there until the whole thing is flowing again Personal examples: The previous incarnation of my study-project ...
Comments
Post a Comment