DEV Community: Antonio De Oliveira Junior

Achieve the power of React hooks and composition

Antonio De Oliveira Junior — Thu, 28 Nov 2019 08:42:45 +0000

React hooks composition proposal

I will quote the README from react-compose-hooks because the motivation is basically the same, I just don't agree 100% with that implementation.

--> The copied text starts here:

Motivation

Side-effect: no one really like them, and within the React ecosystem we've been trying to get rid of them - or at least encapsulate them for good. Hooks seems to go in the other direction, when it encourages people to call a function and expect a dynamic return inside a previously purely functional component. Which leads to...
Not functional: I might be completely wrong with this one, but it seems we've just buried some concepts of functional programming when embracing hooks. No more pure functions, which should always return the same result when called with the same arguments. Which also leeds to...
Testability issues: APIs are certainly to come, but so far we are all sure that using hooks will not encourage testable code at all.

Having all that said, we have to point the obvious answer to all these problems, which is: we already had these problems with classes. This is true, but now we are making the distinction between logic and presentational components much more subtle. Experienced developers are sure going to keep things separately enough, but what about newcommers? They were once tempted to use classes everywhere, and the introduction of purely functional components was a good way to teach them to split logic from presentation. The difference between smart/dumb (container/component, whatever) is now way more difficult to grasp.

Solution

I don't have a final solution. All I know is I've loved the developing experience gains first brought by recompose

--> And ends here.

Those were Lucas Constatino's words.

My two cents

I really love recompose as well, but I can agree that is too much abstraction and high order components.
That said, I think we can use the best of the two worlds.

This is a component using useState and useEffect hooks:

// AppComponent.js
const AppComponent = ({ useFoo, useGithub }) => {
  const { foo, changeFoo } = useFoo("bar");
  const { user } = useGithub("arojunior");
  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <h2>Hello {foo}</h2>
        <h2>Start editing to see some magic happen!</h2>
        <button onClick={() => changeFoo("wooow")}>Change bar</button>
        <div>
          <p>
            <strong>Name: </strong>
            {user.name}
          </p>
        </div>
      </header>
    </div>
  );
};

What is the difference so far? There's no implementation inside the Component. It's using custom hooks and receiving it by props.

The custom hooks:

// AppService.js
import { useState, useEffect } from 'react';

export const useFoo = initialState => {
  const [foo, setFoo] = useState(initialState);
  const changeFoo = value => {
    setFoo(value === foo ? initialState : value);
  };
  return { foo, changeFoo };
};

export const useGithub = username => {
  const [user, setUser] = useState({});

  useEffect(() => {
    const getUser = async () => {
      const githubUser = await fetch(
        `https://api.github.com/users/${username}`
      );
      return githubUser.json();
    };

    getUser().then(u => setUser(u));
  }, [username]);

  return { user };
};

And the magic happens here:

// AppContainer.js
import { withProps } from './utils/hocFactory';
import { useFoo, useGithub } from './AppService';
import AppComponent from './AppComponent';

const AppContainer = withProps({
  useFoo,
  useGithub
})(AppComponent);

export default AppContainer;

Just one HOC and all of the responsibilities are clear.
With this kind of implementation, we can easily test the AppComponent.js as a pure component:

// AppComponent.test.js
describe("AppComponent", () => {
  test("should match snapshot", () => {
    const useFoo = jest.fn(() => ({}));
    const useGithub = jest.fn(() => ({ user: {} }));

    const tree = renderer
      .create(<AppComponent useFoo={useFoo} useGithub={useGithub} />)
      .toJSON();

    expect(tree).toMatchSnapshot();
  });
});

We can also test the behavior (hooks) separated:

// AppService.test.js
describe("AppService", () => {
  describe("useFoo", () => {
    test("should render the correct initialState", () => {
      const { result } = renderHook(() => useFoo("bar"));
      expect(result.current.foo).toBe("bar");
    });

    test("should change foo value", () => {
      const { result } = renderHook(() => useFoo("bar"));
      act(() => {
        result.current.changeFoo("woow");
      });
      expect(result.current.foo).toBe("woow");
    });

    test("should change foo value to initialState when new value is equals to previous", () => {
      const { result } = renderHook(() => useFoo("bar"));
      act(() => {
        result.current.changeFoo("woow");
      });
      act(() => {
        result.current.changeFoo("woow");
      });
      expect(result.current.foo).toBe("bar");
    });
  });
});

And then we can test the two things together, the presentational component and the behavior:

// AppContainer.test.js
describe("AppContainer", () => {
  beforeAll(() => {
    const fakeUserResponse = { name: "Junior Oliveira" };

    jest.spyOn(window, "fetch").mockImplementation(() => {
      return Promise.resolve({
        json: () => Promise.resolve(fakeUserResponse)
      });
    });
  })

  test("Render with useGithub hook and its initial state", async () => {
    const { getByText } = render(<AppContainer />);
    await wait(() => {
      expect(getByText(/Junior Oliveira/i)).toBeInTheDocument();
    })
  });

  test("Render with useFoo hook and its initial state", async () => {
    const { getByText } = render(<AppContainer />);
    await wait(() => {
      expect(getByText(/Hello bar/i)).toBeInTheDocument();
    })
  });
});

What do you think about it? Feel free to comment and discuss about this approach.
My goal is to keep components and behaviors reusable and testable.

Github repository: https://github.com/arojunior/react-hooks-composition-proposal

The best and easy way to handle database migrations (version control)

Antonio De Oliveira Junior — Tue, 22 Jan 2019 00:42:17 +0000

Do know about database version control? It's called migrations and here I will tell you how to do it in a simple way.

If you know about it and work with JavaScript, you probably have tried one of these tools to handle database migrations: Sequelize, TypeORM, Bookshelf, etc… But, seriously… Are you happy with these options? I'm not.

Since I started to work with Java and met the beautiful Flyway, I was missing a tool as great as it is in another languages. And now comes the good news: there's a "dockerized" version that you can use with any language you want!

So if you trust me, keep reading about this magical tool.

The examples bellow are here: https://github.com/arojunior/tests-with-nodejs-graphql

Then we can create the config file and the migrations, as you can see in the volumes arguments.

folder tree

Those names for the migration files are following a convention that you can find here in the documentation, but it's very simple:

filenames convention

Did you notice that the file extension is .sql? Yes! You are able to write plain SQL scripts and don't need to learn a new syntax or object mappings. That's what I love in this tool.

Flyway will create a table to manage the migrations and it runs automagically every time you start the container. It will check the applied scripts and run the new ones. No additional command is needed, you just have to create the new files in the specified folder.

Flyway supports also SQL Server, Postgres, Oracle, MariaDB and more…

Take a look in the documentation for more infos: https://flywaydb.org/documentation/migrations

Now clap your hands for this amazing tool.

Stay up to date with what is happening on Github

Antonio De Oliveira Junior — Sat, 21 Jul 2018 01:55:58 +0000

After hearing several times from some friends who do not use social networks the phrase “my social network is Github”, I decided to make a feed that brings the activities of who you follow in Github. From comments on issues, pull requests, starred repositories, commits and etc … For you to follow everything that is happening in the open source community.

Awesome feed — https://awesomefeed.js.org/

The similar twitter's layout is totally intentional, considering that it is the preferred social network of the open source community.

It still needs to improve a lot, but since I’ve been working alone, it is walking slowly.

You can collaborate on: https://github.com/arojunior/awesome-feed

The tools used are basically: React, Redux, GraphQL, Styled-components and Recompose.

As always, suggestions are very welcome. I'll be waiting for pull requests.

https://awesomefeed.js.org/

Persisting application state with Redux and localStorage

Antonio De Oliveira Junior — Fri, 09 Jun 2017 14:31:57 +0000

Note: It was originally wrote in Portuguese and translated by Google

This library allows you to monitor the status of the application (Redux store) and replicate in localStorage (browser), thus allowing the page to be reloaded without the state being lost.

The first step is to import the library and inform the store

import { createStore, combineReducers } from 'redux'
import storeSynchronize from 'redux-localstore'
import { Reducer1, Reducer2 } from './modules'

const combineReducer = combineReducers({  
 Reducer1,  
 Reducer2  
})

export const store = createStore(combineReducer)

storeSynchronize(store)

Only with bold lines, the entire state of your application will be replicated to the browser ‘s localStorage. The other rows are default settings for Redux application.

As second step, you need to configure the reducers so that they collect this data from the localStorage when the application starts / reloads.

import { defineState } from 'redux-localstore'

const defaultState = {
  data: null
}

const initialState = defineState(defaultState)('Reducer1')

export default (state = initialState, action) => {
  switch (action.type) {
    case 'ACTION1':
      return {
        ...state,
        data: action.payload
      }
    case 'ACTION2':
      return {
        ...state,
        data: null
      }
    default:
      return state
  }
}

The method defineState checks if it has something in localStorage , if it does, it uses it as the initial state … Otherwise, it uses the default state set. Very simple, is not it?

The only detail to note is that the name passed as the second argument to the defineState is the name of the Reducer used in the combineReducers .

The settings are basically these and you can find the library at: https://github.com/arojunior/redux-localstore

Keep working Offline with Javascript

Antonio De Oliveira Junior — Thu, 11 May 2017 12:27:18 +0000

Note: It was originally wrote in Portuguese and translated by Google

Let’s use as an example a system of messages exchange, where each message that you send is stored in a database for later to be displayed to someone. It could be a chat.

Now let’s imagine that you are using this system on your mobile and your connection is suffering oscillations due to bad connection with the carrier… In this case, some of your messages might not be delivered.

Recently I have known the Offline-js lib that monitors the status of your connection, issues alerts in case of drops, alerts when it returns, also monitors ajax requests and tries to resend them as soon as the connection returns.

It also promises to do everything in an “automagic” way, you just need to import the library and that’s it. At first I thought it was beautiful, it was all I needed to solve the issues in my application.

But it is not that perfect. As soon as I started to test with this lib, bugs started to appear … I went to search the issues and had more people with similar problems, but nobody answers the issues! There are also a number of pull requests with fixes and no one accepts.

So I decided to use it as a dependency for some features and make my own implementation: https://github.com/arojunior/handle-failed-requests-js

Promises support (axios)
Uses localStorage to save requests
Saves ALL the failed requests, not just the last one
Requests keep saved even if user try to refresh the page when offline
Sends all requests as soon as the connection is restored
No configuration needed

Use case:

Using this method, whenever a request fails, it will be stored in localStorage and once the connection is restored, it will be sent again.

It is not a silver bullet, it is not about cache as well. You probably are thinking “why don’t you use Service Workers?”. Because SW is not compatible with all browsers, but localStorage is. That’s why.

It is an extremely simple implementation to use and understand. If you have any suggestion, feel free to comment or send pull request.