Taking the time to separate the State, the Store and the Workflow in frontend codebase

For the last two years my team has been continuously refactoring a large legacy app. We learnt a lot of things in the process but one of the most important tools we found was having a new outlook on two core front-end concepts: the State and the Store.

It turned out that cutting problems into State, Store and — as we will see — Workflow “bits” really helped us deliver a better architecture, maintain the codebase in the long term and choose the right libraries to build upon. …

In a previous article we shared how we use opaque and sum types to model a new domain in Typescript.

We built a simple way to write a robust and maintainable domain (in the sense of Domain Driven Design), providing a clean and readable basis to build from further down the line. But, as we will see, it came with boilerplate.

Image for post
Image for post
Photo by SGC on Unsplash

Modeling the domain with our basic opaque-types library

This still works great. Our domain is safe: details of the types are kept private and the users of this message.ts module are forced to use the exposed APIs in order to deal with messages. …

Working on a new feature implies working on modeling the data that comes with it. This step provides a clean and readable basis to build from further down the line. Because of this we are putting a larger emphasis on making sure our model is as robust and maintainable as it could be. Here is how.

Image for post
Image for post
Photo by Anton Darius on Unsplash

The scenario

Imagine we are working on a fancy chat application in which we send many kinds of messages. We could model them this way:

And we would define a union type Message that could be any of them:

Doing so helps a lot (we can for example define a list const messages: Message[] = … without having to deal with variations at that level) but it is not perfect. …

Image for post
Image for post
Photo by ian dooley on Unsplash

New features are unsurprisingly important for iAdvize. Our business relies on the tech team’s ability to develop and implement new features in as short a time as possible. Those will however be challenging, create bugs and they will need to integrate within a sometimes perilous existing code base. They definitely make business sense, but they are technically dangerous.

Business of course prevails, but not a the cost of bad quality software, either external or internal. …

In the big React/Redux application I work on, when I open a {domain}/selectors.js file I often have to face a long list of Redux selectors like this :


At first glance the use of selectors seems harmless, but our current experience has us reaching a different conclusion: there is such a thing as too many selectors, and we have reached this point.

Image for post
Image for post

Redux and selectors

Let’s start with Redux. What is it actually for? A quick look at redux.js.org will remind us that this is a “a predictable state container for JavaScript apps”.

Using Redux, we’re encouraged to write selectors even if they are not mandatory. They are just getters for some parts of the state, ie. functions with this signature : State -> SubState. We usually write selectors instead of accessing the state directly in order to compose them or memoize their results. A sensible endeavour. …

Redux’s connect is ubiquitous in the classic Redux/React application but its most frequent usage has one crucial flaw: it doesn’t account for errors. If connect can’t do that, how can we make sure we’re not letting our view pick up the slack for the holes in our store ?

Imagine a (React-)Redux app where you’re listing entities, in this case let’s say it’s Projects. You typically would have a component somewhere called ProjectList that renders another one called ProjectDetails.

Image for post
Image for post
Our Projects app with a list of ProjectDetails

But because your app is big and ProjectDetails uses other entities (Authors, Clients, etc.), …

And how you can use it too

I am a french Computer Science student at Polytech Nantes, the graduate school of engineering of the University of Nantes, in France. Currently in my 4th year of studies, I have a strong passion for web development, data and AI. This summer I have the opportunity to do a 3-month internship abroad. Therefore I am currently researching companies which might be looking for innovative interns so as to apply. This entails filling applications forms, writing emails and cover letters.

But how to stay organized? This last few weeks I have been using Trello but I was considering using a spreadsheet instead to keep track of applications I have been sending and companies I am in touch with. …

Learn to stay organized by using Trello as your memorising tool

I am a French Computer Science student at Polytech Nantes, the graduate school of engineering of the University of Nantes, in France. Friends and students often ask me to explain how I manage my time and what I do — because, yes, it looks a bit unusual for a 21-year-old man. Here is the post I should have written some time ago.

I want to introduce you to my brain extension: Trello.

In my opinion the service is a very efficient tool an this is why I use it daily (beside Vim, Tmux, Google Calendar, Messenger and Slack). …

Or how to use Wit.ai with Hubot to build your not-so-stupid bot


Image for post
Image for post
Wit.ai quickstart guide : wit.ai/docs/quickstart

So I’ve played a little with Wit.ai with in my mind the idea of building a little bot. Wit.ai is a platform for developpers to easily add natural language recognition to their projects.
It’s 100% free since it was bought by Facebook🤑

There is two main features : Intent and Bot Engine.

Intent is about giving Wit.ai a sentence and waiting for the service to tell us what is it about.

Bot Engine is a little more abstract : it lets you build your own user stories where your user and your service have a real dialog. …

I’m looking for a way to connect a lot of RPI with each other over internet. But I can’t reach them directly (they’re in sub-networks). So I came over the weave solution.

Weave basically create a virtual network through docker container running anywhere. It really amazing, let’s just read the docs.

The problem was that a RaspberryPi isn’t a classic unix machine, docker is not really fully supported. And docker standard x86–64 images won’t run on the Pi but there is hopefully arm images.

So it take me days to make my RPI and my Mac talking to each other in a weave network. …


Guillaume Wuip

Software engineer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store