Nowadays the popular single page applications are everywhere. Having such application means that you need a solid routing mechanism. Frameworks like Emberjs are truly build on top of a Router class. I'm still not sure that this is a concept which I like, but I'm absolutely sure that AbsurdJS should have a build-in Router. And, as with everything in this little library, it should be small, simple class. Let's see how such a module may look like.
If you build web applications you probably communicate with the DOM a lot. Accessing and manipulating DOM elements is the thing which we do almost every day. Very often we collect information from different controls, we need to set values, change the content of div or span tags. Of course there are million libraries which handle these actions. The most popular jQuery, is de factor a standard. However, sometimes you need something smaller. In this article we will build our own class for managing DOM elements.
You probably know the famous quote that the code should be written for humans to understand and accidentally for computers to execute. Writing code that compiles is easy. Writing readable code is completely different thing. Working in a team is like sharing the kitchen with your roommates. You all should care for the dishes and keep clean. And it is not only because of the others but because of you. You don’t want your dinner in a mixed place and dirty dishes right.
I hope you know about currying. If not then please read this book. It’s basically a process of calling a function with less parameters than it expects. Ok, not exactly calling the function but prepare another function that will run the original one. Some people call the returned function higher-order factory function. Really powerful concept.
I’m obsessed by making my code simpler. I didn’t say smaller because having less code doesn’t mean that is simple and easy to work with. I believe that big part of the problems in the software industry come from the unnecessary complexity. Complexity which is a result of our own abstractions. You know, we (the programmers) like to abstract. We like placing things in black boxes and hope that these boxes work together.
I love using functions like
reduce. They are an important part of my arsenal and I simply can’t stop using them. Today I had to solve an interesting problem and I ended up using
The setup here is available at GitHub here.
Half an year ago I published A modern React starter pack based on webpack. The starter provides the basic tooling around React. However, I noticed that very often I need even less stuff than that. That’s usually when I want to hack something quickly. In this blog post we’ll see what’s the bare minimum to work with React.
When we start using React we very soon also start asking questions. Where I’m suppose to put my data, how to communicate changes or how to manage state? The answers of this questions are very often matter of context and sometimes just practice and experience with the library. However, there is a pattern which is used widely and helps organizing React based applications - splitting the components into presentational and containers.
(This article is part of React in patterns series.)
React is highly composable. And the API that enables that is
props.children. It gives us the power to create a placeholder that is later filled with content from the outside.
There are lots of things which I like in React. Mostly the fact that it teaches interesting patterns. One of my favorites ones is higher-order component. In this article we’ll do a couple of experiments and will see how powerful this approach could be.
Sometimes when you learn something new you get really excited. Excited to that level so you want to teach it to someone. That is the case with the concept which I found a couple of months ago. It is an implementation of the command pattern using generators. Or the well known saga used in the redux-saga library. In this article we will see how the idea makes our asynchronous code simpler and easy to read. We will also implement it ourself using generators.
Redux is a library that acts as a state container and helps managing your application data flow. It was introduced back in 2015 at ReactEurope conference (video) by Dan Abramov. It is similar to Flux architecture and has a lot in common with it. In this section we will create a small counter app using Redux alongside React.
If you use React you probably know about the so called hooks. They were officially announced at this year's ReactConf by Sophie Alpert and Dan Abramov. Their presentation could be seen here. I, same as many others got intrigued by this new feature. A little bit confused by if I like them or not but kind of excited. This article pretty much sums up my thinkings around React hooks and aims to give a balanced opinion.
The hooks API is a wonderful idea. There are some slick patterns involved that push the React development to a more functional approach. I'm interested in trying that new API and decided to use it for my latest project. However, after a couple of days, it looked like I can't build my app only with hooks. I needed something else. And that's mainly because each hook works on a local component level. I can't really transfer state or exchange reducers between the components. That's why I created Jolly Roger. It has similar helpers but works on a global app level.
This weekend I decided to play with the new kid on the block - Facebook's Recoil library for managing state. I did the trivial counter example to see how it works. It's pretty simple idea so I wondered how much it takes to replicate its features. I found the exact answer - 70 lines of code. Obviously, my implementation didn't cover everything but it was fun so I decided to share my findings.
(A side note: I did not look at the code of Recoil. I didn't want to be bias on how to write my version.)