First, I must apologize. This could have been a story about how and when to use comments in code, but it’s not. It’s about being a respectable human being.
Since we started this Medium publication, we have stuck to technical topics and shied away from giving strong opinions. We want this publication to be useful for both new and experienced developers, and we are not into endless debates that, for the most part, end up being a matter of taste and preferences. However, when the year is coming to an end we always write a piece where we reflect about…
We have been teaching React for several years now, both to our peers at Trabe and to employees of companies that hired our services. Since the introduction of Hooks we have adapted our courses for beginners. As of now we start by teaching Function Components, then we jump to Class Components, and lastly, we introduce Hooks.
In March 2019, I came upon a tweet that started a very interesting thread (I’ve wanted to write about this for months, never got the time. It’s still relevant, though 😌):
One particular answer, from Kent C. Dodds, a very well known figure…
It’s possible that you still don’t know this:
The Promise returned from
fetch()won’t reject on HTTP error status even if the response is an HTTP
500. Instead, it will resolve normally (with
okstatus set to
false), and it will only reject on network failure or if anything prevented the request from completing. (Fetch API — MDN)
I find myself explaining this during PRs and training sessions more often than not, so I thought that I might as well write it down. …
Some days ago I wrote about using functions and composition instead of hoarding props to define flexible React components. I would like to dig deeper into this concept outside the scope of React.
In this story we’ll make a refactoring exercise to get to a conclusion: functions and composition can help us build flexible APIs that are easy to understand, maintain and extend.
Let’s start coding a synthetic example: a data fetching operation. It allows us to use options to configure how the data is fetched and the response handled:
The other day I was refactoring some tests so I made a wrapper to access some mocked information with ease. This wrapper contained some getters and one of them retrieved a value asynchronously. Unfortunately, JavasScript syntax does not support asynchronous getters.
async get syntax but you can rely on several workarounds.
As you should know by now:
Async functions always return a promise. If the return value of an async function is not explicitly a promise, it will be implicitly wrapped in a promise.
Authorization, frontend-wise, is just showing or hidding stuff. In React apps the usual way to handle authorization is having a component that conditionally renders its children based on some authorization condition (having a specific login or having some role, for example).
Let’s assume that we have some sort of authentication mechanism and using a Hook we can get the current user: a simple object with all its authorization related information.
Using this Hook we can create a
Visible component that receives a prop for each condition we want to check.
And we can use it in our code:
One of our customers gives us user-by-user access to their systems through a proprietary VPN that we cannot set up on our CI infrastructure.
When we need to deploy their Rails application we rely on mina scripts that connect to the deploy machines using SSH connections (over the VPN). To work properly mina needs you to exchange SSH keys with the server. These are legacy projects, so we use Docker to run our local development environment. So, how can we deploy using Docker?
One option would be to create a new shared deploy key for the project using
The React docs say this about Portals:
Portals provide a first-class way to render children into a DOM node that exists outside the DOM hierarchy of the parent component.
This means that they are the tool to use when we need to render parts of our UI in a different layer. What makes them awesome it’s how portals behave:
Even though a portal can be anywhere in the DOM tree, it behaves like a normal React child in every other way. …
When you want to have real time updates on a web application, you can rely on old-fashioned periodic polling or try to use some push capable modern technology. Your first impulse may be using WebSockets. However, if you just want to receive data from the server you can use Server Sent Events.
Traditionally, a web page has to send a request to the server to receive new data; that is, the page requests data from the server. With server-sent events, it’s possible for a server to send new data to a web page at any time, by pushing messages to…
Some of our intranet backends use S3 storage and GraphQL APIs. It’s a common scenario nowadays. This story is about how we deal with file attachments in our schemas and how our client code can get hold of the real files.
Let’s start with a very simple server:
Co-founder @Trabe. Developer drowning in a sea of pointless code.