Just deleted the 500px and Instagram apps
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.
I finally got my invite to Micro.blog in the end of October. And I got to say: it’s awesome.
Micro.blog feels a lot like what App.net felt like, and a lot like Twitter in the old days.
I would encourage everyone that miss those times to check it out. It feels very beta at the moment, but it will get there.
There aren’t many things I’m worse at than keeping up with anniversaries and stuff like that. Part of the reason is that I write most of the post from a few weeks to a few months before they are going live, so I have little to no connection to when something will be live. That has the added benefit of me doing everything I can to make them have as little connection to “right now” as possible.
By the time this goes live I would have written this blog for over two years. A lot have happened over that time. These days I’m more or less happy with the kind of stuff I’m using. And the main area of experimenting is new inks. I might try a couple of new notebooks a year, and I only get new pens when I see something I don’t have in some pen I discover.
I guess I have moved over to what I really wanted this site to be about. Writing more about using the products, than the products themselves. And how to go about figuring out the perfect stuff for me. Rather than reviewing all the Lamy Safari or TWSBI colors.
What if I actually manages to schedule this post for the real anniversary next year?