https://i.redd.it/vezwyo0qq4lz.png
regarding that image:
1) they show a raw call to postgres npm/pg → that’s an old pattern that involves writing SQL (difficult, unsafe)
Now we have modules that write the SQL for us (better safety, easier)
npm/sequelize is imperfect but pretty good for most work
—
it does show the solution to the browser pre-fetch OPTIONS call CORS bug! so they do know what they’re doing, it’s just old code
2) their reducer is written in the old style switch-case structure… I use the lookup-hash pattern
https://github.com/reactjs/redux/issues/883
look at the object that he passes to createReducer
that’s the pattern from tahini (and the new react underground) that I was convinced to use by the same fellow who convinced me to move to React
— -
Object.assign is good to know for when you don’t have { …obj } (that is, in nodejs)
3) the async action is written as a thunk (think of dispatch as the callback function to trigger another action)
that’s an old pattern that you still see sometimes, using npm/redux-thunk, which is a general purpose redux async middleware — so general purpose that it can do anything, but doesn’t add any meaning to our code beyond “this is an async thing”.
the fetch is a new API, so once again this image mixes stuff I don’t like with stuff I do
4) the purpose of my current react-underground is to “do all the plumbing and gluing together for you — you just write the unique parts of your component”
The reason for that is because the plumbing and gluing together is always the same, so standardizing it makes your components easier to test and understand.
Here you see they’ve (implicitly) imported the someFunction (which is a poorly named thunkActionCreator) — and they haven’t explained that this.props.dispatch (in ContainerItem component) is passed to the component by npm/react-redux’s connect HOC
They also haven’t used the state which their async action is fetching and grafting onto the global redux state, or explained how to use the connect HOC to map from global redux state to the component’s props (mapStateToProps)
also their constructors are all entirely worthless
also it’s conventional to
import React, { Component } from ‘react’;
and not use
class StupidComponent extends React.Component { /* … */ }
but rather
class DoesTheSameThingComponent extends Component { /* … */ }
in short, it looks like this code was written by someone who writes Angular, as it used some modern web browser APIs and followed a pattern
however, the pattern is not optimized or really fully explained by the presented code
— -
I would say it is important that you be able to read that code and be able to analyze it as I just did without ever running it (running it would involve fixing some imports and API endpoints, running a postgres instance (with a data structure and SQL statement) and connecting to it, using react-redux to connect your component to the state after instantiating your React app, and even then it wouldn’t do anything because the ContainerItem doesn’t do anything from the state)
—
overall, I like this picture, it uses good technology and presents a very consumable look at a full stack javascript data-flow
it it valuable to review and understand, and hopefully learn from along with my criticisms of it (examples of which I should make my version of this from)
