Forem: Francesco Pigozzi

What's the worst part about the JS ecosystem?

Francesco Pigozzi — Tue, 17 Aug 2021 07:37:12 +0000

Seriously, give me your honest opinion and save any rant: what's the worst part about being a developer in the JS ecosystem? What makes you roll your eyes up to the sky? What makes you wondering if you've chosen the right developer career?

Also, most importantly:

What would you change, if you could?

Let me know in the comments 👇 or just leave a 🦄 and share this discussion 📣

Thanks for reading 🙏

The story behind savethebees.cloud and its bees’ movement 🐝

Francesco Pigozzi — Wed, 26 May 2021 18:03:49 +0000

Photo by Ralph (Ravi) Kayden on Unsplash

TL;DR

I created this landing page and wanted to make it cool so I used SVG's animateMotion, docs here

The story

If you find stories boring stuff, skip this section

It was a day like many others in Cubbit and suddenly a message was sent to the whole company saying that we have started an internal referral program 🎉

What a perfect opportunity to finally build something I had in mind for quite a long time: a landing page with animated bees, Cubbit's symbol, and strong empathic messages with the goal to spread our mission as much as possible.

Also, the best opportunity for everyone to get access to a nice discount code

Creative process

A wise friend once said: programmers, when they have an idea, start coding immediately and this is the worst error you could do!

So, a huge step back and we are ready to start designing something and this is the result of the first draft of a sketched minimal bee.

Not very interesting, uh? Asking for feedback is the best way for you to come to better solutions. So I asked to my girlfriend.

This is the final result

Way better, Lovely

So, now it’s time to start coding, right? Wrong

First of all, you wouldn't go far with just a bunch of bees flying around and..

Wait, HOW THE HECK DO I MAKE THEM FLY? Ok, I will think about this later.

Now it's time to design some interfaces, maybe a story line and, why not, a prototype!

The very first frame looked something like this, a little bit boring, though.

I've tried several ways to improve it and, at the end, I decided to apply some blur to it

Way better, now the user won't pay much attention to the bees' details and will focus on what I have to say: time for some text!

This is good already but looks a little too flat, without any depth and some bees might interfere with the focus on the text, even if they are blurred.

The same wise friend I was talking about before gave me a cool trick that designers adopt when it comes to typography and readability

Again, some feedback to the rescue!

Shadows are magical

These screens are already the final result that you can enjoy on the live page

Coding, finally!

Just to give you some small details, this site is built with React, TypeScript, styled-components, React Transition Group and a lot of sense of humor. It's hosted on Vercel, of course.

Ok, building the interfaces, preparing all the styles and scaffolding the codebase was the simple part and now come the troubles

Quoting myself

HOW THE HECK DO I MAKE THEM FLY?

And this has been the longest and toughest challenge of this project

CSS transform

Ok, the very first thing I tried was to wrap everything into multiple transformed containers with some properties like translate3d and rotate3d ; the 3d part is necessary to access the hardware acceleration

And it started to work fine until I decided to animate the bees automatically, with some sort of algorithm and random numbers: a complete failure

When you deal with CSS and Javascript at the same time, you can't benefit from both with a solution that involves both of them: my problem was the huge load of computations that the main thread had to handle in order to find the next possible point for a bee to move to

You can already understand that this solutions doesn't scale up very well

Thank you, next!

SVG to the rescue!

So, after the previous failure I started wondering: isn't there a way to smoothly animate an SVG without using any JS and/or CSS?

After googling a bit (ok I admit it, after googling a lot), I stumbled across this documentation on our beloved MDN: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/rotate#examples

And everything started to be magical and possible again 🌈

This article represents the exact solution I was looking for!

The problem is not to move the bees in a random set of points generated at runtime; instead, you should focus on a set of already defined paths and let the SVG magic do the rest 🧙‍♂️

This is the export of the SVG of the bee with the path

The final code of the Bee

I won't make it any longer, here you can find the resulting code of a React component, with CSS transforms, SVG elements and animations

import React from 'react';
import styled, { keyframes } from 'styled-components';

const vibration = keyframes`
    from,
    to {
    transform: translate3d(0, 0, 0);
    }
    10%,
    30%,
    50%,
    70%,
    90% {
        transform: translate3d(-3px, 0, 0);
    }
    20%,
    40%,
    60%,
    80% {
        transform: translate3d(1px, 0, 0);
    }
`;

const VibratingWings = styled.g`
    animation: 1s ${vibration} infinite;
`;

type TransformProps = {
    x?: number;
    y?: number;
    rotation?: number;
}

const BeeSVG = styled.svg<TransformProps>(({x = 0, y = 0, rotation = 0}) => ({
    position: 'absolute',
    transform: `translate3d(${x}px, ${y}px, 0px) rotate3d(0, 0, 1, ${rotation}deg)`,
}))

type Props = {
    debug?: boolean;
    duration: number;
} & TransformProps

function Bee({debug, duration, ...transformProps}: Props) {
    return (
        <BeeSVG
            {...transformProps}
            width="422"
            height="552"
            viewBox="0 0 422 552"
            fill="none"
            xmlns="http://www.w3.org/2000/svg"
        >
            <g clipPath="url(#clip0)">
                <path
                    id="motionPath"
                    d="M80.4017 146.011C80.4018 1.26631 376.903 53.5395 339.785 146.011C302.666 238.483 69.0275 297.382 80.4017 402.125C91.776 506.868 339.784 543.688 339.785 402.125C339.785 260.562 80.4017 290.757 80.4017 146.011Z"
                    stroke="black"
                    strokeOpacity={debug ? '1' : '0'}
                />
                <g clipPath="url(#clip1)">
                    <path d="M0 13L3 11.268L3 14.7321L0 13Z" fill="#434141"/>
                    <mask id="mask0" mask-type="alpha" maskUnits="userSpaceOnUse" x="2" y="5" width="16" height="16">
                        <circle cx="10" cy="13" r="8" fill="#E6CC74"/>
                    </mask>
                    <g mask="url(#mask0)">
                        <path d="M10 21C5.58172 21 2 17.4183 2 13C2 8.58172 5.58172 5 10 5C14.4183 5 18 8.58172 18 13C18 17.4183 14.4183 21 10 21Z" fill="#E6CC74"/>
                        <path d="M8 -3L8 29H5L5 -3L8 -3Z" fill="#434141"/>
                        <path d="M14 -3L14 29H11L11 -3L14 -3Z" fill="#434141"/>
                    </g>
                    <VibratingWings>
                        <path d="M10.4645 3.53551C12.0266 5.09761 12.0266 7.63027 10.4645 9.19236C8.90238 10.7545 6.36972 10.7545 4.80762 9.19236C3.24552 7.63027 3.24552 5.09761 4.80762 3.53551C6.36972 1.97341 8.90238 1.97341 10.4645 3.53551Z" fill="#B5D2FF" fillOpacity="0.6"/>
                        <path d="M11.1716 2.8284C12.7337 4.3905 12.7337 6.92316 11.1716 8.48526C9.60953 10.0474 7.07687 10.0474 5.51477 8.48526C3.95268 6.92316 3.95268 4.3905 5.51477 2.8284C7.07687 1.26631 9.60953 1.26631 11.1716 2.8284Z" fill="#B5D2FF" fillOpacity="0.8"/>
                        <path d="M10.4645 22.4853C8.90238 24.0474 6.36972 24.0474 4.80762 22.4853C3.24552 20.9232 3.24552 18.3906 4.80762 16.8285C6.36972 15.2664 8.90238 15.2664 10.4645 16.8285C12.0266 18.3906 12.0266 20.9232 10.4645 22.4853Z" fill="#B5D2FF" fillOpacity="0.6"/>
                        <path d="M11.1716 23.1924C9.60947 24.7545 7.07681 24.7545 5.51471 23.1924C3.95262 21.6303 3.95262 19.0976 5.51471 17.5355C7.07681 15.9734 9.60947 15.9734 11.1716 17.5355C12.7337 19.0976 12.7337 21.6303 11.1716 23.1924Z" fill="#B5D2FF" fillOpacity="0.8"/>
                    </VibratingWings>

                    <path d="M16.5 11C16.5 11 19.25 10.5 20 10C20.75 9.50002 21 8.00002 21 8.00002" stroke="#434141" strokeWidth="0.2"/>
                    <path d="M16.5 15C16.5 15 19.25 15.5 20 16C20.75 16.5 21 18 21 18" stroke="#434141" strokeWidth="0.2"/>

                    {/* https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/rotate */}
                    <animateMotion dur={`${duration}s`} repeatCount="indefinite" rotate="auto">
                        <mpath href="#motionPath"/>
                    </animateMotion>
                </g>
            </g>
            <defs>
                <clipPath id="clip0">
                    <rect width="422" height="552" fill="white"/>
                </clipPath>
                <clipPath id="clip1">
                    <rect width="26.0208" height="22" fill="white" transform="translate(22) rotate(90)"/>
                </clipPath>
            </defs>
        </BeeSVG>
    );
}

export default Bee;

BeeSVG is the wrapper around the SVG and it accepts some props in order to make the entire SVG transformable; in order to place the bees in a random position and rotation inside the page

VibratingWings is a styled g element that lets the wings simulate a vibration

animateMotion with rotate="auto" is my best friend for this project

Considerations

Ok, I have to admit that I like a lot this final solution but unfortunately it's not performing very well neither; even though it runs at 60fps on average devices

I think that in the next releases I'll think about moving to WebGL in order to benefit from real hardware acceleration

Now it's your turn!

Let me know what you think about this article and, of course, don't forget to visit my, and Cubbit's, pages about the real problem: our world is suffering and the bees are dying 🐝🌎

Don't let this happen, take action! Whatever you can do is enough, you don't need to make anything big!

Start with the simple things, like me!

I'll bee around

Hope that you enjoyed this little story and have learned something new!

Leave a 🦄, if so, and a 🐝 in the comments!

My first Open Source library

Francesco Pigozzi — Mon, 25 Jan 2021 07:25:28 +0000

Thanks to Lisheng Chang @changlisheng for making this photo available freely on Unsplash 🎁

Long story short

It all started as a pet project, I know you understand me.

But rapidly it became more like a developer need: to have something that works as you want it to, something you could share with other developers and be proud of it because, damn, you’ve just became part of an amazing ecosystem called Open Source!

I was finding myself in the need of using the plain JS SDK of Amazon’s Product Advertising API, link here, but it was barely usable, with a lot of conventions, zero explicitness and a whole set of unreadable code.

Maybe it’s just me but in the past year I’ve started to appreciate when you jump into a project and you can understand easily how things get passed around. I needed Typescript.

There was little to no libraries as I expect them to be and finally I came to one conclusion: I needed to do it myself.

And I did it! 👇⭐️

Pigotz / paapi5-typescript-sdk

TypeScript SDK for Product Advertising API 5.0

paapi5-typescript-sdk

Unofficial TypeScript SDK for Product Advertising API 5.0

Installation

In order to install this SDK, you just have to run you well-known npm or yarn scripts:

npm i -S paapi5-typescript-sdk

yarn add paapi5-typescript-sdk

And there you go! Enjoy 😎

API

Everything is exported from the SDK: requests' classes, models, utility types, helper and so on..

If you want to import everything

import * as SDK from 'paapi5-typescript-sdk';

And use what you need later

const request = new SDK.SearchItemsRequest(/* ... */);

You can refer to the Amazon Product Advertising API 5.0 for further details about every request

Auth

In order to validate all the requests against the APIs, I've implemented almost from scratch the AWS V4 signing process, creating the SignHelper class.

This is intended for interal use, but if you want to use it for other purposes, here you can…

View on GitHub

I need feedback 🙆‍♂️

This is a small project but a whole set of TS is involved and needs to be maintained ⚙️

This is my first time being the author of an Open Source repository so any feedback and proposal is welcome 🙏

If you are just lazy, leave a GitHub ⭐️ and a 🦄 here, it would be enough for me!

Thanks for reading!

Stop using the title "Full stack developer"

Francesco Pigozzi — Mon, 28 Dec 2020 17:00:00 +0000

Photo by Christina @ wocintechchat.com on Unsplash

TL;DR

The title Full stack developer has really nothing to do with you as a developer, instead it's something strictly related to the company's stack, as the name suggests, and, unless the company is sharing its stack with the world, no one will ever guess which technologies and languages you are working with and master.

On the other hand, if you work as a freelancer, the title might suggest that you are some king of tech God, no matter what is the challenge; sounds pretty presumptuous.

Later in this article I have some suggestions for different job titles that would better fit your real skills, if you are interested keep on reading 👀

Skills, "I" people and "T" people

I won't go deeper in this field since there is already a well done article about this; I'm just gonna steal some cool images from there.

As you can see from the image above, there are three types of people when we talk about skills: I-shaped, T-shaped and Generalists.

Usually, a Junior Full stack is something like a generalist and, with more and more experience, they will eventually become a T-shaped developer by starting to master a specific set of technologies.

There might be outstanding developers in the wild that will eventually become Square-shaped developers, mastering everything; you can do it if you follow your dreams! But this is not the point.

My adventure

Take me as an example: I've started as a Generalist, knowing a little to zero of everything but still very presumptuous, probably affected by the Dunning-Kruger effect, reference below.

The Dunning Kruger Effect

Idrees Dargahwala ・ Sep 10 '19

#psych #programming #productivity

But I had a lot of enthusiasm and will to learn new things ASAP; that permitted me to slowly become an I-shaped developer, specialized in front-end development, UI, UX and stuff.

Fortunately, that was just a tiny step and I didn't lose my will to learn different skills and I've never lost my horizontal set of skills, even if it was a very thin line.

Later in my career I had the chance to finally work as a Full stack developer! But I've always had this question in my mind: how could you call yourself a Full stack developer if you din't work with every single technology out there?

But the dream of finally writing Full stack developer in my LinkedIn profile and everywhere else was too big to find an answer. How naive I was... this story sounds the more stupid the more I tell you.

Social reputation

If you are reading this article, probably you went through the same thoughts as I did:

Why not writing that job title if I know a lot of stuff?
It will help me find a better job next time
It rocks
I feel like a Senior developer
It's time to do it

I get your point

It's all about reputation, social image, portfolio stuff maybe.

But let's be realistic: you need a better way to sell yourself. Remember my first words in this article?

no one will ever guess which technologies and languages you are working with and master

And this my friend, is the real problem to solve.

In her shoes

Imagine being a recruiter searching for new developers to get in touch, you know little to nothing about programming languages and related technologies but your boss said "We need to find a proficient C# developer for ACME company with at least 40yr of experience with MongoDB and Linux" (I wrote a no-sense position on purpose, follow me).

Then, always as a naive recruiter, you take that sentence for granted and start looking for profiles with your brand new LinekdIn Premium profile.

After some search, you find a dozen of Full stack developers and in your head that title sounds very cool, the right person I'm looking for! Someone with a wide knowledge, he/she must be who I'm looking for!

You see the problem here? The person on the other side of the screen doesn't give a heck about what your stack really means. It's your responsibility to specify it!

A possible solution

I have quite a few, let's briefly see them.

If you really trust your knowledge, experience and will to learn, then Software Engineer might appropriate and less confusing. With that title, you want to say that the field or the technology doesn't matter: you are ready to learn anything because you are prepared for that.

If you have a very little horizontal set of skills but you master a field, just go for the title of that field: if you are a Frontend developer, just say that, there's no need to hide it. Also, if you are an Embedded Software developer, a Data Architect, whatever. You will change that title with something like the ones below when you will be ready.

Last, if you don't see yourself in any of the title above, nor you can relate with any of the letter-shaped cases at the beginning, I have a proposal for you.

Let's say that Full stack feels very presumptuous, right? Now, imagine describing your stack of skills with something different than Full, what could it be? There are plenty of dimensions before that, something like Thin Stack developer, Wide Stack developer or Huge Stack developer.

This new titles, my dear friend, will arouse curiosity in who will read them since no one uses them yet! That's why, once you choose the best title for you, it should be useful to create something that will better describe what you mean with that: GitHub pages, a custom Portfolio site, something like this.

Time to discuss

I know, I know: some of you couldn't wait to see the final point of my article just to let me know that you strongly disagree with it.

But, hey! This is just my opinion about this, I can't wait to hear yours in the comment 👇

Last, but not least, react with a 🦄 if you've found this article interesting! 👏

Why you should consider joining Cubbit

Francesco Pigozzi — Tue, 16 Jun 2020 06:51:43 +0000

Photo by Eric Ward on Unsplash

TL;DR

We are looking for new developers to join us, here is the link to the careers' page.

But if you want to learn more, from an internal developer, keep reading; and you will find how deep is the rabbit's hole.

Cubbit, who?

Started a few years ago from the genius mind of our CTO and his co-founders, Cubbit aims to be the next-gen of cloud computing as it should have always been: distributed, green and private by design.

Don't get me wrong, I'm not trying to sell you anything, we already have folks for that and they do a much better job than me, really.

I'm here to tell you my experience among these amazing guys, how we work day by day with cutting edge technologies and shape the future of cloud together.

Off topic: the video below is amazing!

Why should you listen to me?

Well, you don't have to indeed. Feel free to close this article now.

I'm just another enthusiast developer who's trying to sell his job position as the best one ever, right?

WRONG

Indeed, I'm not sure that a lot of you could resist a single day with our rhythm and standards in fact of code and tech quality (this is provocative on purpose).

If you don't trust me, go and check it yourself here.

Again: I'm not selling you anything, just showing you the truth.

But is it worth it?

Yes, it is worth every single hour spent on brainstorming with my colleagues, worth every single problem we faced, worth every line of code we wrote.

Cubbit is a company that makes Technology as its product, not really common, and makes it aiming for excellence, every day, by every 🐝 in the Swarm.

My journey

I joined Cubbit in late 2019 but I knew the brilliant minds behind the scenes way long before.

My first day of work was on October 14, 2019; since that, time flew with an incredible speed as we worked on a lot of different faces of our products and delivered the best value possible to all our bakers and users.

9 months have passed and there wasn't a single moment of boredom: code to write, code to review, brainstorming to do, moments of team building, interns and juniors to work with and a lot of technology to learn, EVERY SINGLE DAY.

COVID-19

Sadly, in March 2020 a huge pandemic hit all around the world and you know that Italy was one of the most affected countries.

You know what changed drastically since that moment? Nothing.

Cubbit had the strength to react to this bad boy by allowing remote work for everybody, as many other companies did, and our productivity dropped little to nothing.

Our team is strong and passionate, who better than us knows that together we are stronger?

Just like bees 🐝

Now it's your turn 👇

As I said before, we are searching for new developers to join us to get bigger and even stronger, always together!

Feel free to ask me anything you want, here in the comments or by direct messages on LinkedIn.

We have open positions in the careers' page of our site or on LinkedIn itself.

If you are a really lazy person (not cool) here are our job descriptions for both fullstack and frontend.

You can send your CV and/or your portfolio at careers@cubbit.io.

Thank you 🙏

If you still aren't considering joining us, I want to thank you anyway for reading my article: this means a lot to us!

As my last wish, let me ask you to leave a 🦄 so that this article can be spread as much as possible!

See you in the Swarm, bye! 🐝

Check out this new library: useWorker

Francesco Pigozzi — Sun, 15 Mar 2020 10:30:58 +0000

Hi there! 👋

A friend of mine made this tiny library that lets you use Web Workers with ease in a React application.

Check it out and leave a feedback 🦄

Social skills for tech folks (?)

Francesco Pigozzi — Sun, 01 Dec 2019 16:16:31 +0000

Hi all!

I'm trying to write down something about one of the most terrifying things to deal with for tech folks: social skills.

It is known that almost all of the people that work in IT prefer to interact with a machine rather than a human.

Am I wrong? What do you think about it?

Tell me a story about that time you struggled with talking/interacting with another human and why.

Which social skill is the most important to you? Why? Is it empathy? Maybe sincerity?

I look forward to hearing your answers!

How to store relational data inside Redux

Francesco Pigozzi — Wed, 03 Apr 2019 19:44:17 +0000

Photo by Tobias Fischer on Unsplash

Sooner or later, all frontend developers need to save relational data in a Redux store.

TL;DR

Follow the advice of Firebase, they are very useful.

Data

Whether they come from APIs or static payloads, based on relational DBs or not, the data has relationships between them.

We will define resources all those types of data that could have relations with other resources.

An example resource could be a post from our personal blog.

This post will have a 1:1 relationship with the author (from the point of view of the post, we will see that an author will have a 1:N relationship with posts) and a 1:N relationship with comments.

An inefficient structure

Let's say that our personal blog should only present a list of posts and a detail page for each of them.

For this specific example we could have, in our Redux store, a first level key containing all our posts indexed by id. Within each one we could nest the author's data and comments.

const store = {
  posts: {
    'p123': {
      id: 'p123',
      title: 'Best React pattern in the world!',
      author: {
        id: 'a123',
        name: 'Francesco',
        email: 'name.surname@gmail.com',
      },
      comments: {
        'c123': {
          id: 'c123',
          body: 'Best article ever!',
        },
        'c124': {
          id: 'c124',
          body: 'Best article ever ever!',
        },
      }
    },
  }
}

// And so on, you get the point

The problem occurs if I wanted to create a page for the author's profile with a list of his posts.

To take an example with Redux selectors, we could retrieve the data we need in this way:

// This returns an array of posts
const getPostsByAuthor = authorId => state => (
  Object.values(state.posts).filter(post => post.author.id === authorId)
)

// And you'd call this selector like this:
const state = store.getState()
const postsByAuthor = getPostsByAuthor('a123')(state) // [...]

But it would be particularly inefficient to be able to get what we need: every time we should go through all the posts.

A weighted structure

A weighted structure could be a 1:1 representation of the hypothetical tables within our relational DBs.

const store = {
  posts: {
    'p123': {
      id: 'p123',
      title: 'Best React pattern in the world!',
      author: 'a123',
    },
  },
  author_posts: {
    'a123': ['p123'],
  },
  authors: {
    'a123': {
      id: 'a123',
      name: 'Francesco',
      email: 'name.surname@gmail.com',
    }
  },
  post_comments: {
    'p123': ['c123', 'c124'],
  },
  comments: {
    'c123': {
      id: 'c123',
      body: 'Best article ever!',
      post: 'p123',
    },
    'c124': {
      id: 'c124',
      body: 'Best article ever ever!',
      post: 'p123',
    },
  },
}

In this case we removed the nesting problem. However, we added two new first level keys to our Redux store.

This approach is not totally wrong but, as our application grows, it may be difficult to manage all relationships efficiently.

It could be a usable approach if the amount of resources is limited. But it is also true that, if the amount of resources is limited, we may not really need Redux.

An efficient structure

Following the recommendations of Firebase, we could save ourselves some first level keys:

const store = {
  posts: {
    data: {
      'p123': {
        id: 'p123',
        title: 'Best React pattern in the world!',
        author: 'a123',
      },
    },
    comments: {
      'p123': ['c123', 'c124'],
    },
  },
  authors: {
    data: {
      'a123': {
        id: 'a123',
        name: 'Francesco',
        email: 'name.surname@gmail.com',
      },
    },
    posts: {
      'a123': ['p123'],
    },
  },
  comments: {
    data: {
      'c123': {
        id: 'c123',
        body: 'Best article ever!',
        post: 'p123',
      },
      'c124': {
        id: 'c124',
        body: 'Best article ever ever!',
        post: 'p123',
      },
    },
  },
}

Unlike Firebase, we are not going to nest relationships with "placeholders".

Instead, we organize our first-level keys as small second-level store containers.

Do you think of something similar thinking about the reducers and the combineReducers function? Same logic: we reduce our global object to the smallest representable portion.

Bonus: how to structure selectors

After having structured our Redux store, the first question that could come to your mind could be: how do I get this data?

Here are some simple selectors.

// Base data

const selectAuthors = state => Object.values(state.authors.data)
const selectAuthor = id => state => state.authors.data[id]

const selectPosts = state => Object.values(state.posts.data)
const selectPost = id => state => state.posts.data[id]

// Totally useless
const selectComments = state => Object.values(state.comments.data)
// Maybe useless
const selectComment = id => state => state.comments.data[id]

// Relations

const selectAuthorPosts = authorId => state => {
  const authorPosts = state.authors.posts[authorId] || []
  return authorPosts.map(postId => selectPost(postId)(state))
}

const selectPostComments = postId => state => {
  const postComments = state.posts.comments[postId] || []
  return postComments.map(commentId => selectComment(commentId)(state))
}

Conclusion

Now you could structure a Redux store to save relational data. It could be overkill in some cases but it will come in handy to handle more complex applications.

Leave a 🦄 if you liked the post!

What kind of articles do you like the most?

Francesco Pigozzi — Sat, 16 Mar 2019 07:29:16 +0000

TL;DR

Do you prefer casual or super technical articles?

Let me know

I started a few weeks ago to write in this network and I already feel at home.

I usually like to write about JavaScript, React, Redux and, soon, even Rust.

I would like to be able to write something that you all can enjoy without being bored or confused.

Write in the comments what you think about and leave a 🦄!

Redux middleware as pure functions

Francesco Pigozzi — Fri, 08 Mar 2019 19:16:25 +0000

Source of inspiration

I decided to write this article after seeing this video by Nir Kaufman. Do not be scared by the title, it's within reach of any developer with a minimum of imagination and sense of humor.

What is a Redux middleware?

A function. Really, nothing more.

Actually, it's a function that returns a function that returns a function that does something.

Something like this:

const middleware = () => () => () => {
  // Do something
}

It looks a lot like a normal Javascript's closure, isn't it?

Let's review it populated by some parameters:

const middleware = (store) => (next) => (action) => {
  next(action)
}

Let's analyze the parameters that are passed to it:

store: the actual store of Redux, from which we can deconstruct getState and dispatch
next: the next middleware
action: the action that has been dispatched

It is necessary to call next(action), otherwise the flow will be blocked (this does not have to be a negative thing).

Pros and cons about using one or more custom middleware

Pros

Freedom of implementation
No pattern constraints, just a few suggestions
No bottlenecks hidden somewhere, just pure functions

Cons

Freedom of implementation
No pattern constraints, just a few suggestions
No bottlenecks hidden somewhere, just pure functions

No, you didn't become crazy: I deliberately returned the same points. This free approach is very powerful but very dangerous if not used in the right way: you could find yourself managing performance drops only due to a poor implementation or management of a side-effect.

The classic scene where the developer plays both the sheriff and bandit roles.

Remember the words of Uncle Ben:

Why should I build one or more middleware, then?

Well, you don't really have to.

The alternatives are varied and vast: just think of redux-thunk, redux-saga and many others. They are all middleware in turn, do their work and some of them are also very performing.

That said, if you still think that you want to use a library, I will not stop you. Actually, I'm a big fan of redux-saga!

Just a few suggestions

Let's now see together, referencing to Nir's suggestions, some patterns that can be used immediately.

Filter

const middleware = (store) => (next) => (action) => {
  // Avery action with type BAD_ACTION will be removed from the flow
  if (action.type === 'BAD_ACTION') return

  next(action)
}

Map

const middleware = ({ dispatch }) => (next) => (action) => {
  // We don't want to remove this action from the flow
  next(action)

  if (action.type === 'ACTION_FROM') {
    // Instead, we want to fire a side-effect
    dispatch({ type: 'ACTION_TO' })
  }
}

Split

const middleware = ({ dispatch }) => (next) => (action) => {
  // We don't want to remove this action from the flow
  next(action)

  if (action.type === 'ACTION_COMPOSED') {
    dispatch({ type: 'ACTION_FIRST' })
    dispatch({ type: 'ACTION_SECOND' })
  }
}

Compose / Aggregate

Compose and Aggregate are similar in their behavior.

To differentiate them we could simply say that the first logic expects more actions of the same type and then generates a unique side-effect, similar to a buffer; the second logic expects actions of different types.

To achieve this, we need to introduce the concept of middleware status. Thus creating what I like to call stateful-middleware.

Let's see how to implement this pattern in order to generate a side-effect, without blocking the flow.

// We are not defining a middleware, we are defining a middleware's factory
const makeMiddleware = (waitFor, waitTimes, handler) => {
  let actions = []

  // Here we are returning a middleware
  return (store) => (next) => (action) => {
    next(action) // We aren't blocking the flow

    if (action.type === waitFor) {
      actions.push(action)

      if (actions.length === waitTimes) {
        // We then pass to the handler all the actions
        handler(store, actions)

        // We may then reset the "state" to start again
        actions = []
      }
    }
  }
}

Or using a blocking approach.

// We are not defining a middleware, we are defining a middleware's factory
const makeMiddleware = (waitFor, waitTimes, handler) => {
  let actions = []

  // Here we are returning a middleware
  return (store) => (next) => (action) => {
    if (action.type === waitFor) {
      actions.push(action)

      if (actions.length === waitTimes) {
        // We then pass to the handler all the actions blocked before
        handler(store, actions)

        // We may then reset the "state" to start again
        actions = []
      }
    } else {
      next(action)// We are blocking the flow
    }
  }
}

Deciding to block or not the flow is up to you, both cases could be useful to solve different problems.

To go from Compose to Aggregate it will be enough to allow the factory to verify that the action that it's been intercepted is among those that should be waited for.

// snip
// Where waitFor is an array of action types like ['ACTION_A', 'ACTION_B', 'ACTION_C']
// Boolean is unecessary, just for clarity
if (Boolean(~waitFor.indexOf(action.type))) { /* snip */ }
// snip

Enrich

This pattern turned very useful for me for adding, for example, a timestamp to some actions.

const middleware = (store) => (next) => (action) => {
  if (action.type === 'ACTION_TO_ENRICH') {
    next({
      ...action,
      payload: {
        ...action.payload,
        '@': Date.now(),
      }
    })
  } else {
    next(action)
  }
}

Normalize

const middleware = (store) => (next) => (action) => {
  if (action.type === 'ACTION_TO_NORMALIZE') {
    // Clone payload, it will be less painful to modify it
    const payload = { ...action.payload }
    if (typeof payload.postId === 'number') payload.postId = payload.postId.toString()

    next({
      ...action,
      payload,
    })
  } else {
    next(action)
  }
}

Translate

Indeed, I do not think I have a real example for this pattern. If you can think of a better one, please let me know in the comments!

const middleware = (store) => (next) => (action) => {
  if (action.type === 'ACTION_TO_TRANSLATE') {
    next({
      ...action,
      type: 'ACTION_TRANSLATED',
    })
  } else {
    next(action)
  }
}

How to integrate these newly created middleware

I will not go into the merits of how to create a Redux store, you've done it thousands of times. Rather, I will show you how to apply these middleware to the newly created store.

Do not take this example literally, there are many ways to handle more and more middleware within the codebase. This approach is the simplest that came to my mind.

import { createStore, applyMiddleware, compose } from 'redux'

import rootReducer from './rootReducer'
import initialState from './initialState'
import { someFilterMiddleware, someMapMiddleware, someComposeMiddleware } from './middlewares'

const customMiddlewares = [
  someFilterMiddleware,
  someMapMiddleware,
  someComposeMiddleware('ACTION_TO_WAIT', 2, (store, actions) => console.log(actions))
]

const configureStore = () => {
  // Spread them as arguments for applyMiddleware
  const middlewares = applyMiddleware(...customMiddlewares)

  const store = createStore(
    rootReducer,
    initialState,
    compose(middlewares),
  )

  return store
}

export default configureStore

Attention!

All of this is very nice, but the fact remains that, the more middleware created, the more the number of functions through which an action must pass before reaching its destination increases. Rather, you might prefer a mono-middleware approach that can handle a series of major cases if, and only if, some criteria are met: something similar to redux-saga.

redux-saga is structured in a single middleware, which runs a generator-runner over and over, as long as there are actions to be interpreted or effects to be dispatched. We will not go further.

What's the point?

The point is that you do not really need a particularly complex or engineered library to manage application side-effects or business logic in a modular way.

Do you need to manage a login? Create a middleware. Don't you need it anymore? Disconnect the middleware from the flow and you won't have to act elsewhere.

There is no more versatile thing than being able to use any pattern, conventions or browser API to achieve a goal.

You can use closures, factory, iterator (why not), setTimeout, setInterval or the newest requestIdleCallback API.

Again, I am not saying that this approach can completely replace a single and more structured middleware. After all, if certain libraries were born, they had excellent reasons. I just wanted to share with you a way to handle some logic that was different from the usual.

Thanks everybody!

Thank you for reading this article until the end! If you liked it, leave a 🦄!

If you do not agree with what I wrote, leave a comment and share some ideas!

React Redux Connectors pattern

Francesco Pigozzi — Wed, 06 Mar 2019 21:50:17 +0000

TL;DR

Don't worry, I'm not here to talk about the umpteenth react-redux-whatever package.

This post is rather a moment of reflection on what could be a simple but powerful approach to avoid generating dependencies between what would be called containers and what we normally call components.

Many of you will have found their way to solve this problem; for those who did not, keep reading.

The problem

How many times have you found yourself in front of a new project, maybe created using create-react-app, armed with good intentions not to repeat the same mistakes that have generated technical debt in previous projects? I already imagine many of us at that precise moment:

"This time the codebase will be well structured", "The folders will have only one level of subfolders, maybe two" or "I will not bind the components to the containers again".

The last famous words.

The reasoning

When we talk about containers, we are defining nothing but components that are enriched with information from a HOC: connect.

The problem is not about writing mapStateToProps, mapDispatchToProps and mergeProps (yes, there is a third parameter and it is fantastic) again and again and again. The problem is, rather, to know what to do with these components connected to the Redux store.

"Do I include the presentational logic within them? But if I have to move it or modularize it, I should rewrite everything ..."

The naive solution

"Actually I don't see all this distinction between components and containers ... Now I will make sure that every component can access the status of Redux when and how it wants, after all we are talking about Context".

Connectors (?)

For some time I like to ask myself the question "how would I like to write it/use it ?" before implementing any utility in Javascript or React.

In the same way, to solve this problem, I would like to write something like this:

<Layout>
  <Layout.Header>
    <h1>Header</h1>
  </Layout.Header>
  <Layout.Main>
    <PostsConnector>
      {({ posts }) => posts.map(post => (
        <div key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.body}</p>
        </div>
      ))}
    </PostsConnector>
  </Layout.Main>
</Layout>

This way of looking at it reminds me a lot of the Javascript closures.

After all, React is a powerful library for the fact of leaving freedom and dynamism to the developer to be able to create as preferred the tree of components, either in JSX or not.

Why, at this point, I can not take advantage of some generic Javascript programming concepts in order to solve this kind of specific problems?

Connector's creation

// imports

class PostsConnector extends Component {
  componentDidMount() {
    const { fetchOnMount, fetchPosts } = this.props

    if (fetchOnMount) {
      fetchPosts()
    }
  }

  get childrenProps() {
    const { posts, fetchPosts, createPost } = this.props

    return {
      posts,
      fetchPosts,
      createPost,
    }
  }

  render() {
    const { children } = this.props

    return children(this.childrenProps)
  }
}

// PropTypes and connect's logic

Or using React Hooks

// imports

const PostsConnector = ({
  children,
  fetchOnMount,
  fetchPosts,
  // Redux
  posts,
  fetchPosts,
  createPost,
}) => {
  useEffect(() => {
    if (fetchOnMount) fetchPosts()
  }, [])

  return children({
    posts, fetchPosts, createPost,
  })
}

// PropTypes and connect's logic

Done ✅

Bonus: `composeConnectors`

All this is very nice but .. "If I had more connectors inside each others?".

In this specific case, your problem may be to have too many connectors.

In the case, however, you still want to proceed and try to avoid the connectors-hell and write something like this:

const ComposedConnector = composeConnectors(
  <PostsConnector />,
  <PostConnector postId="super-secret-id" />,
)

<ComposedConnector>
  {props => console.log(props) || null}
</ComposedConnector>

You can use this utility function:

import React from 'react'

// return ({ children }) => (
//   React.cloneElement(connectors[1], null, secondProps => (
//     React.cloneElement(connectors[0], null, firstProps => (
//       children({ ...firstProps, ...secondProps })
//     ))
//   ))
// )

const composeConnectors = (...connectors) => (
  connectors.reverse().reduce((composed, connector) => (
    ({ children, ...childrenProps }) => (
      React.cloneElement(
        connector,
        null,
        connectorProps => composed({ ...childrenProps, ...connectorProps, children }),
      )
    )
  ), ({ children, ...props }) => children(props))
)

export default composeConnectors

Thanks for reading

If you liked this article just let me know; if not, let me know it anyway.