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.
This article is about Stent - a Redux-liked library that creates and manages state machines. Stent implements some of the Redux’s core ideas and in fact looks a lot like it. At the end of this post we will see that both libraries have a lot in common. Stent is just using state machines under the hood and eliminates some of the boilerplate that comes with Redux’s workflow.
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.
I really like Redux. I Love its ideas. The reducers for example - small pure functions that apply changes without side effects are nice way to model the mutations in the state. Redux also teaches us to use the one-direction data flow which makes our apps more predictable and stable. These two things fits well for what we are doing on the front-end - building user interfaces.
Of course there is nothing perfect and Redux as every other library has its own problems. In this article I want to explore some ideas for new APIs that will help solving the problems that I encounter. I’ll be happy to see your comments below.
Something bugs me last couple of years. I'm using React for some time now and there is always this doubt if I'm placing the business logic on the right place. I'm trying to be pragmatic, to follow best practices and listen what the community is saying. However, I still feel that something is not ok. This blog post presents the idea of the reactive view. That is nothing new per se but I came up with this term because it fits well in my idea.
Riew is a library based on communicating sequential processes (CSP). It is made to help with communication and synchronization between your view and business logic. It's distributed as a npm package, it has 0 dependencies and adds ~8KBs (gzip) to your application on production.
In this article we will see some use cases of Riew. Those are patterns which I found repeating while using the library. There are other blog posts part of the same series and I will suggest checking at least this one so you get a basic understanding before jumping into the code snippets below.
I'm working on a small library that has a logger. I'm bundling the app to a single file and I want to disable the logger for the production version. In this blog post we will see how I removed the
logger.log calls from my bundle using AST (abstract syntax tree).
I'm now actively working on a VSCode extension. I started it as a theme but then decided to add some more features. Like for example a tin line on the left side of the editor marking the current function scope. In order to do that I had to analyze the current file's code and find the lines that are included in that scope. The obvious approach will be to translate the code to AST and then traverse the tree finding the information that I need. This however will require the usage of a language server which now I don't want to deal with. So I decided to explore a brute force approach. Looping over the string characters and finding balanced matches. I quickly wrapped it into a library. I called it Pairify. It consumes text and returns an array of pairs. This blog post will show you how it works.
I ❤️ markdown. I like its simplicity and minimalistic API which is good enough to cover most of needed HTML markup. At least for textual content. At work we have a small node based microservice that delivers data from Contentful in exactly markdown format. It's all working well but we started having cases where part of the text is in Contentful and the other part is in that microservice. For example when we have a button with a catchy design. We want to content manage the label of the button but the actual markup to be on our side.
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.)