I totally do. I keep a paper note book where I keep drawing layouts before creating dom notes, jsx templates and whatnot. Sometime I even name the different components I'm going to create on that sheet of paper, and then recreate it all on html and css .. Normally I don't do the same with logic thou ..

Watch out! 4) A user with a completely valid age of 0, gets a age set to 27!!

Indeed. Webpack just bundles your code, doesn't fetch or keep package dependencies. It's npm/yarn for me currently .. preferably yarn

Smart components can, and will, have all sorts of DOM nodes and other components (smart or dumb) to which it's going to pass props to. You can, however, have smart components as higher order components wrapping other components, but your answer would be completely different for someone who is new to the Redux ecosystem

This is a very nice one indeed. Comprehensive, well used graphics, and very insightful.

Let me try, even thou English is not my main language ... Redux (the Flux methodology) is based on having an only source of truth, the state object, which will be kept available by all the reducers, and a only one way of updating the data and showing it on your views. Initially, the components you connect to certain parts of this state are subscribed to the changes it may suffer along the way, and will represent the data on your views, but different to the common mvc pattern, the only way to alter the state from any components is via the use of action creators. Action creators are functions that calculate or fetch data, hold or use the logic you need, to send the reducers an/some/many actions (objects with a part of the current state you'd want to change). All actions need a type , and different payloads depending on what you may want to change, so the reducers can mix/merge/assign new data to the current state to produce a new state (yes, the state should never be mutated, you always get a new one!). These are normally triggered by user actions, but could also be internal state so your views can tell the user when something is loading, or has an error, ie. Reducers, finally, are switches that are subscribed to the different parts of the state, pretty much as your components, but also to your actions, so when a particular action is fired, some reducer subscribed to this action can then mix the state with this piece of data and return the new state. There can be several reducers listening to the same action type, and all of them are passed through your actions as you are composing your root reducer .. Does this help?

I'm good with just Atom or Visual Studio Code .. still have my handy Sublime Text around sometimes even .. (mainly when I need to touch files in three different languages, for the different color scheme for each one) ..

No IDEs, but plain Atom

We are using axios as our main http request library and JWT tokens for authentication, and it's so easy to select the instance of axios you are using, and modify the headers to be sent as per session basis .. export default function setAuthToken ( token ) { axios.defaults.headers.common[ 'Authorization' ] = '' ; delete axios.defaults.headers.common[ 'Authorization' ]; if (token) { axios.defaults.headers.common[ 'Authorization' ] = ` ${token} ` ; } } With this little guy, we are able to set the default headers for all axios calls after a user has authenticated (you'll see we force the cleaning of headers to avoid problems with duplicated Bearers, and to be able to re-use the function to clear out the headers) We also store the JWT in localStorage, so it gets rehydrated if the user reloads the page .. Hope this helps

I was to write something similar. Well said. The base is always needed, no matter on what final library or framework you are going to be using. Learn JavaScript.