DEV Community: Geraldo dos Santos

The new magical Redux land.

Geraldo dos Santos — Thu, 19 Aug 2021 08:17:48 +0000

This post assumes you have worked somewhat with Redux before, so apologies in advance if the syntax/explanations make little sense to you. 🖖

In the beginning...

...back in the age of class components, a fair amount of tutorials out there would always teach React + Redux together, like they were necessarily part of each other.

What often happened is the steep learning curve of those two put together would make people have not so positive feelings towards one or the other (but very likely Redux was the one liked the least).

Dispatch, reducers, action creators, containers...

I mean, looking back, I can understand the feeling very well.

What I experienced:

// Having your container components (the ones that do the Redux magic)  

function mapStateToProps(state) {
  // Pass the global state down as you want it
}

function mapDispatchToProps(dispatch) {
  // Bind your action creators and have your components accessing them
}

export default connect(mapStateToProps, mapDispatchToProps)(MyContainerComponent);

Then wrap all the components under your container component and go to Redux town. Now you are able to update and read the global state in your application.

Oh and don't forget your reducers!

I remember when our team back then was going through all that and often feeling overwhelmed, because of so many layers, so many moving parts. Little did I know what the future would hold.

But I ended up not using redux for nearly two years because of my new job. We didn't need it, so I never heard of it again, until...

Fast forward 2 years.

Another day, another side project

Recently, during a random talk with a good colleague of mine, he mentioned being enthusiastic about Redux and that sparked my curiosity, so I decided to check it out, and oh boy.

We can build something cool with it.

Let's fetch Magic The Gathering cards.

In order to get started, we need a store.

// src/store/index.js

import { configureStore } from "@reduxjs/toolkit";

const store = configureStore({ reducer: {} });

export default store;

That's it. In their docs you can check how it was before, and the pleasants surprises didn't stop there.

Now we need reducers.

Redux Toolkit has reducer slices, and what are those?

slice reducer: a reducer that is being used to handle updates to one specific slice of the state tree, usually done by passing it to combineReducers

(from their docs)

Basically, it's a more focused reducer, it's easier to split the state changing logic instead of having one gigantic reducer that does a lot.

This is how you create a slice:

// src/features/search/searchSlice.js

import { createSlice } from "@reduxjs/toolkit";

const initialState = {
  searchString: ""
};

export const searchSlice = createSlice({
  name: "search",
  initialState,
  reducers: {
    searchCard: (state, action) => {
      // Redux Toolkit allows us to write "mutating" logic in reducers. It
      // doesn't actually mutate the state because it uses the Immer library,
      // which detects changes to a "draft state" and produces a brand new
      // immutable state based off those changes
      state.searchString = action.payload;
    }
  }
});

// Action creators are generated for each case reducer function
export const { searchCard } = searchSlice.actions;

export default searchSlice.reducer;

Like it's mentioned in the code and their docs, there's no need for spreading objects over and over again. Redux Toolkit already takes care of the immutability for you, so feel free to assign the value to the state directly. Never again overwriting the state by accident!

Notice how we didn't have to create any actions? createSlice already does it for you, combined with a reducer. But if you want to create those by hand, feel free to check the createReducer on their API.

Cool, our slice is ready. We can finally connect it to the store:

// src/store/index.js

import { configureStore } from "@reduxjs/toolkit";
import searchReducer from "../features/search/searchSlice";

export const store = configureStore({
  reducer: {
    search: searchReducer
  }
});

Now we're ready to use it in our components.

Interacting with our components

Remember connect, mapStateToProps and mapDispatchToProps?

This is them now, feel old?

const search = useSelector((state) => state.search);
const dispatch = useDispatch();

useSelector is how we tap into the global state shared by your store.

And useDispatch allows us to dispatch our actions. But where do we get our actions from?

From the slice! 🤩

import { search } from "./features/search/searchSlice";

Putting it all together:

// src/App.js
import { useDispatch, useSelector } from "react-redux";

import { searchCard } from "./features/search/searchSlice";
import "./styles.css";
import { useCallback, useEffect, useState } from "react";
import { useUpdateEffect } from "react-use";

export default function App() {
  const searchState = useSelector((state) => state.search);
  const [card, setCard] = useState(null);

  const dispatch = useDispatch();

  const handleChange = useCallback(
    (searchString) => {
      if (!searchString) return;

      fetch(
        `https://api.scryfall.com/cards/named?fuzzy=${encodeURI(searchString)}`
      )
        .then((response) => response.json())
        .then((jsonResponse) => setCard(jsonResponse));
    },
    [setCard]
  );

  useUpdateEffect(() => {
    handleChange(searchState.searchString);
  }, [searchState]);

  return (
    <div className="App">
      <h1>
        Would you like a magic card?{" "}
        <span role="img" aria-label="card">
          🃏
        </span>
      </h1>
      <div style={{ marginBottom: "2rem" }}>
        <label htmlFor="card-search">Card select: </label>
        <select
          id="card-seard"
          onChange={(event) => dispatch(searchCard(event.target.value))}
        >
          <option value="">Choose one</option>
          <option value="lightning bolt">Lightning bolt</option>
          <option value="ancestral recall">Ancestral Recall</option>
        </select>
      </div>
      <div>
        {card?.image_uris && (
          <img
            src={card.image_uris.normal}
            alt={card.name}
            style={{ height: "300px" }}
          />
        )}
      </div>
    </div>
  );
}

I'll leave the running sandbox here:

Conclusion

Despite this being a simple example to add Redux on, I wanted to share how much easier it is to get started on it. Something I plan to write about later is their RTK (Redux Toolkit) Query. Adding on this post would make it too convoluted.

I was completely blown away from what it can do and I definitely recommend checking it out.

After playing around with all for a bit, I ended up creating this fun side project, take a look if you're into tabletop RPGs: www.yougotaquest.com

How to keep all moving parts insightful?

Geraldo dos Santos — Sat, 10 Aug 2019 09:14:53 +0000

Hey you,

How do you keep all the moving parts of the applications you work on easy for newcomers to join? How much documentation do you use (if any), or do you draw diagrams?

Maybe a gear diagram?

As your applications scale up and evolve, how do you keep track of its components in such a way that doesn't require too much brain power to remember how it all ties together?

What did and/or did not work for you? Please share your story. 😊

A test to remember

Geraldo dos Santos — Sun, 14 Apr 2019 11:35:11 +0000

The team I work in once came across a very interesting material about unit tests. How to do it in a more relevant way, testing what matters.

While it was interesting, something else caught my attention. The speaker pointed at test names. He brought to light some conventions followed to this very day, namely the combination of Should, Given, When, and Then.

Take a look at this test example and the conventions behind it, I want to test the Withdraw method from my BankAccount class.

So...

Given my bank account is in credit, and I made no withdrawals recently
When I attempt to withdraw an amount less than my card's limit
Then the withdrawal should complete without errors or warnings

Ok. Keep that in mind.

You are a new engineer at the team, you will be working in the BankAccount class for the next couple of days. Andrew, a guy who started a couple of months before you, is showing you the ropes. You're taking a lot of notes to make sure you get the details.

Suddenly, Andrew needs to attend a meeting and leaves you looking at the editor. He asks you to keep playing with the code, looking at the architecture, and to write down questions you might have for when he's back.

You get particularly curious about the Withdraw method in the class you're looking at. You feel you kinda get it, but not quite. Head scratches and frowning keep intensifying.

Eventually you find a unit test for it, and this is what you see.

public void Given_BankAccountInCredit_When_WithdrawIsMade_Then_ShouldSucceed()

While you're at it, you heard that one of your colleagues did well in a Magic the Gathering tournament during the weekend, and because so, she decided to bring cake to the office today.

That was Tina, she's one of the engineers working in the BankAccount class.

You go to Tina after getting one (or more, I'm not judging) slice(s) of cake, then you ask her:

"Hey Tina, thanks for the cake btw! Question, I'm not completely sure what the Withdraw method should do in the BankAccount class. Would you be so kind to explain it to me?"

"Sure, dude. Here's how it goes."

"Given my bank account is in credit, and I made no withdrawals recently, when I attempt to withdraw an amount less than my card's limit, then the withdrawal should complete without errors or warnings."

"That's it, any questions?"

"So, it withdraws money."

"Yup."

"Cool, thanks."

Please prescind from how trivial withdrawing money from an account is and bear with me. I believe there is no need in making the code have such noise when explaining what it does. Naming things is hard, I know, but that is no excuse to make it harder on the reader. Conventions are good, they help us establishing order among the chaos. Then comes maturity, and it's ok to experiment with what you learned, go beyond just that's what the rule says.

Imagine reading hundreds, or thousands of tests written like this, filtering through all those words to understand what's going on. Imagine someone new joining the team, and having to go through all those noisy test names.

When having a chance to explain something to someone, you would not deliberately choose the most difficult and convoluted way to make that person understand what you are clarifying. I know that there's a subreddit about explaining things in a easy way, but haven't found one yet about doing the same in a hard way.

If I would create such a test, it would be like this:

public void Withdraw_Removes_Money_From_Account()

No Shoulds, no Givens, Whens, Thens for the sake of the convention. The name says it all using as few words as possible.

Need more specific scenarios? Awesome! Your tests should be specific so your the logic in your code can be generic.

public void Withdraw_Removes_Money_From_Account()
public void Withdraw_Fails_When_Account_Is_Blocked()
public void Withdraw_Fails_When_Amount_Exceeds_Daily_Limit()
public void Withdraw_Fails_When_Amount_Exceeds_Total_Balance()

This is it, the tests say exactly what happens, and the convention I choose to use is write tests readable for humans.

Some dude out there once said this:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Do you concur?
How do you and/or your team write test names?
Want to share more examples?

Thanks for reading, peace!