I have never built anything with MobX, and I don’t think I will, unless it’s forced down over my head. But I’m pretty sure that if I had the choice between a job where I worked with redux or one where I worked with MobX, I would have chosen the former; much like I would have if I had the option between a job where I used React and one where I used Vue or Angular.
I’m not sure how it makes stuff easier, but it does at least move state management out of your components. Look here if you want a sample project / tutorial.
If you think functional programming isn’t your thing, or something like that I would look at MobX. One of the things I have heard about MobX is that it requires less code than redux. But I don’t see anything in MobX that lets you place the state anywhere in the component three like you can with redux. And the whole decorator thing feels a little bit too much like Java programming for my taste.
I don’t mind Java or C# as a backend language, but I don’t think those ideas are that great when it comes to frontend development.
It might be the right thing for you, even though I don’t like it; especially if you don’t like redux.
Just deleted the 500px and Instagram apps
What kind of read it later service / app are you using?
A Redux Store consists of a few different parts. You always have a single store, that uses either a single Reducer or Multiple Reducers (through Redux’s CombineReducers method). And you dispatch actions to your reducers. (You also have the initial state for each reducer, that is the default values)
Store = is like an instance of a class. It contains the actual data.
A reducer takes the current state + an action, applies it to the state and returns the new state.
If you look in the gist above you see everything you need to set up a basic redux setup. You can make it how simple or complex you want to. I personally just make multiple reducers, and action-creator methods that update them.
The awesome thing about redux is that it isn’t a “react thing”. This means that you could use the same state layer with any front end library or framework.
If you want to use it with react then you need two things from the the react-redux package: Provider and Connect.
You place the around the JSX code in your ReactDOM render() method in your entry point. And then you use the connect() method to map functions and state elements to your components.
You map state elements to your components so that what is in redux are passed as props to your components, and you map your action creators to your component through connect so that the action creators have access to your store’s dispatch method.
Something like this:
As usual, the code above is working, but you need to add some imports etc to have a working example.
Okay. So redux is a very simple solution to manage state. It has a few different parts, but none of them are difficult to understand, and it is very easy to work with. I don’t think I ever see any bugs in that part of my code bases.
Let’s begin with the reducer. A redux setup consists of one or more reducers. A reducer is a function, plus the inital state. The reducer function is usually a large or small switch / case. You are free to write it exactly how you like, but it has to return a new version of your state, and it recieves a object as input.
The typical way to do it is to use a TYPE key in the object to tell what kind of change it is, and then some additional data, if needed.
Important: input to a reducer is a pure object, and the output is a pure object.
Then you have your actions, this is the stuff inside the switch / case.
Then you have action-creators. These are functions that you use, and the result is that an action is invoked on the reducer. For example: load data from backend, and then add that data to the store.
This is the important part. You create a redux store, with one or more reducers. This is a instance of your store. Then you can use the dispatch method on that store object to send actions to it, or to get the current state.
You can either use it directly, but that would be a little bit “cumbersome” using React. What most people are doing is to create the store, and then add it to the Provider component in React-Redux. And then use connect.
The way this works is that Provider add your store as a context, and then the connect function, component or what ever use it, and you first run it through a function where you chose what properties from the state you need, and then you run the function that returns with your component as a argument. It can also map any methods to dispatch.
Or, if you don’t want to do that, the dispatch method will be available as a prop on all component you run through connect.
A few implementation tips at the end. Don’t connect props you don’t need, and only connect them where they are needed. There is no need for passing stuff down through long component structures with Redux. And make multiple smaller reducers rather than a few large ones. One patter I’m a huge fan of is to use a higher order function to make a re-usable reducer for everything related to lists, with the redux part being re-usable and the matching and talking with backend functions as params.
The next post will be redux example.
I’m pretty sure I won’t start developing my own film any time soon, but I really enjoy scanning the negatives myself.
The official Context API documentation says that it is experimental, and that you should avoid using it. I don’t use it, and I have never done so with anything that is in production. I personally think that using for example redux solves many if not most of the problems that most people try to solve with the Context API.
I’ll explain what it is, and what it does, even though I don’t recommend it at the moment.
Context is a second way to pass data between components. It got a lot more attention when I started to learn react. The reason is that the API never was stable enough to be worth the hassle to be honest. What Context tries to solve is the problem of passing data through components structures without having to pass the prop through every single Component.
Let’s say you have Five components nested under each other.
Like this: Comp1->Comp2->Comp3->Comp4->Comp5, and you have a element in Comp1 state, that tells what kind of colour the button in Comp5 should have. You define a “getChildContext” method in Comp1 that returns an object which is the context, and then everything under that component may access the context through this.context.
As of React 16 aka fiber the Context API is broken. There is a api for updating the context, but it is broken. It might be because it will be deprecated or because it will be fixed in some future release. I personally think that redux solves most of these problems, because you can pass props to any component anywhere in your code base without going through deep component structures.