DEV Community: Ryan Yurkanin

Algebraic Effects Help Us Optimize for Change

Ryan Yurkanin — Fri, 08 Feb 2019 00:45:01 +0000

When a function has to interact with anything other then itself it's emitting side effects.

function double(x) {
  if (!Number.isFinite(x)) {
    return console.error(
      `double(x): ${x} is not a number`
    )
  }

  return x * 2
}

double is handling an error here by logging with console. The cause and handler of the effect are colocated.

Some of our users love this; some hate it. What if they don't want double logging in production, or they pay for error reporting software they want to hook into?

We need to lift the handling of this effect up. How do we signal that an effect should be handled though?

We could do that using callbacks and something like an onError argument.

function double(x, opts) {
  if (!Number.isFinite(x)) {
    const error = `double(x): ${x} is not a number`;
    if (opts.onError) {
      return opts.onError(error)
    }

    return console.error(error)
  }

  return x * 2
}

This solution has some serious issues at scale. It causes drag while refactoring and makes it harder for new developers to fall into the pit of success.

Good Architecture Helps Codebases and Developers Scale

Imagine having to write code in a layer that lives between double and the rest of the code.

import double from "./double";

// How were we supposed to know we get a second argument
// that has an onError function?
function doublePlusOne(x) {

  // if double isn't a number, it will return a string!
  return double(x) + 1;
}

You will break code if you forget to pipe onError through, or if you don't know that double returns early on error.

This is the version that handles those edge cases.

import double from "./double";

function doublePlusOne(x) {
  return double(x) + 1;
}

If we didn't have to handle these cases and instead could magically connect the cause of the effect to the handler life would be easier for everyone.

function double(x) {
  if (!Number.isFinite(x)) {
    throw `double(x): ${x} is not a number`;
  }

  return x * 2
}

// We don't have to be aware anymore!
function doublePlusOne(x) {
  return double(x) + 1;
}

// anyone consuming our code can wrap at the top level!
try {
  doublePlusOne("😵")
} catch (error) {
  ErrorService.log(error);

  if (!env.PROD) {
    console.error(error)
  }
}

This is a large part of what makes an effect algebraic. doublePlusOne can exist without being aware of the side effect.

Any code added inbetween is safe from that mental overhead.

Learning from `Try/Catch`

How would you recreate try/catch in Javascript if it wasn't a default part of the language?

throw stops at the first catch block it encounters, allowing for a top level default that can be overriden.
When we throw the call stack is discarded. This let's us break the rules of any language that works primarly with return.

Programming languages like Koka and Eff make algebraic effects first class citizens, however Javascript does not. You could build try/catch in those languages.

Javascript doesn't expose the tools we need to create algebraic effects, but it does expose abstractions like try/catch and async/await.

While engineering, change and iteration can be rapid. The speed at which we can collaborate and refactor is key to getting a quality end result.

Imagine if we could extract the essence of try/catch and apply that to other programming concepts such as fetching data.

In this imaginary land, when Javascript finds a fetch.throw it would start looking for a handler.

const fetch = new Effect();

function double() {
  const x = fetch.throw("number");
  return x * 2
}

try {
  double()
} fetch.catch(resume, ...args) {
  // resume lets double() continue running with the value!
  if (property === "number") {
    API.get("/number").then(
      response => resume(response.data.number)
    )
  }
}

You may have noticed resume being passed into the handler. In languages that expose algebraic effects they usually have a way to return to where the throw occured.

How Does This Help Optimize for Change?

Earlier in this article, I talked about how we had to "lift the handler up", in order to expose behavior.

I like to think of "Time to Refactor" as a very important part of any API. If an effect pipes through code as you move the handler up and down you have to clean up/pipe it through relevant spots.

Algebraic Effects minimalize the amount of code you have to touch, which means:

PR's will be smaller making code review quicker and less intimidating.
Iterations will take less time and be smoother because you don't have to touch every file in between the effect and the handler.
There are less chances to make a mistake and silently break other parts of the codebase.

Wrapping Up

Algebraic effects make two parts of our codebase aware of side effects: where the effect fires and where it is handled.

By speeding up the refactor cycle, we can iterate faster. You rarely have to touch where an effect is fired, or the in between code of the codebase. Often you just move the handler up and down some levels.

It also gives those consuming your codebase free entry points to integrate. As long as this is documented and exposed, you gain a lot of flexibility for free.

If you have any questions or are looking for one-on-one React mentorship, feel free to tweet me @yurkaninryan any time!

Good luck and happy coding!! 😄

Understanding Reducers: You Can Use Them Without Redux

Ryan Yurkanin — Tue, 22 Jan 2019 14:11:15 +0000

TLDR: You can handle state with a reducer in your Class Components by having one function that translates actions into state changes. It centralizes all your setStates.

🤔 What is a Reducer?

Reducers are functions that take input and decide what to do it with it in one central spot. That's it. 😄

For example, if you have a function that determines the view to show based on a URL, it's a url view reducer.

Redux Reducers™️ are a specific application of reducers that interpret events in your application, and how that changes application state.

this.dispatch("RESET_COUNT_CLICKED")

If you aren't familiar with Redux, the above example is usually kickstarted by calling a dispatch function with an action (object describing an event). 📣

We can use reducers right now in a class component by creating a function that handles setting the state by an action type like so:

Using a reducer in this simple example is overkill in my opinion. I'm glad React is going to be providing both a useState and useReducer hook for that reason.

If I noticed I was passing down ways to change the state, and count became coupled with a few more state properties, I would switch to a reducer.

Since Redux puts all of its state in one object that grows quickly, it makes the reducer pattern a perfect fit. It's possible to remove reducers from Redux, even though we would lose a ton of awesome features.

Redux lets you connect your global store to your component. You can translate state into props. They also provide a dispatch function that triggers your reducers.

Instead of passing a dispatch function, let's pass in an update function that works like setState.

💩 Creating a ~Worse~ "Different" Version of Redux

When you call update, you are saying exactly how the state should change inline. It may or may not be next to other similar state changes.

With a small enough state, this actually feels nice and concise. If we had 5 or more components changing a few state properties it would be hard to find the source of bugs. 🐛 🕵

Even without changing redux at all you can emulate this pattern. Dispatching actions that look like SET_COUNT are hints we really just want setState. It's the easy thing to do.

If we create a less opinionated action likeINCREMENT_BUTTON_CLICKED we could use it in many reducers, and the action payload wouldn't vary too much.

💡 Reducers Are Useful for More Than State

The input here is the current URL, the output is the view!

Reducers are a great way to colocate decisions. If you've worked with react-router-4 before, then the above code should look pretty familiar.

Thanks to the <Switch /> component, we can nest these route-view reducers anywhere.

Now if someone has the question "What are all the ways the URL can change what renders", they have one central place to look.

🏆 Summing It Up

Reducers as a pattern exist outside of Redux and Javascript and are simple to implement. They have one single responsibility of taking input and giving output.
Redux Reducers turn app events into state. You don't need Redux to do this now, you can do it with local component state.
Reducers make it easy to organize and find different variations of what can happen in the code and are useful as apps grow large.

If you have any questions or are looking for one-on-one React mentorship, feel free to tweet me @yurkaninryan any time!

Good luck and happy coding!! 😄

Why React Hooks, and how did we even get here?

Ryan Yurkanin — Tue, 22 Jan 2019 14:01:10 +0000

React Hooks are here, and I immediately fell in love with them. To understand why Hooks are great, I think it helps to look at how we've been solving a common problem throughout React's history.

Here's the situation. We need to build a button that allows a user to send and receive messages through it. It must show old messages, listen for new messages, and change the document title to alert them accordingly.

For this exercise, let's ignore the presentational bit. We're going to focus on the logic surrounding the data. We can start by making a shell of a component and fetching data on mount.

class Intercom extends Component {
  state = { messages: [] };

  /* Once this component is rendered, it will grab all the old messages */
  componentDidMount() {
    API.getMessages(this.props.user.id, data =>
      this.setState({ messages: data.messages })
    );
  }

  render() {
    return (...);
  }
}

Easy enough. Now we need to set up a subscription for new messages, and clean up when we unmount.

We should keep a seperate state key for new messages because we will need to differentiate in the future.

class Intercom extends Component {
  state = {
    newMessages: [],
    messages: []
  };

  updateNewMessages = data => {
    this.setState({
      newMessages: [...data.messages, ...this.state.newMessages]
    });
  };

  componentDidMount() {
    API.getMessages(this.props.user.id, data =>
      this.setState({ messages: data.messages })
    );

    API.subscribeToNewMessages(this.updateMessages);
  }

  componentWillUnmount() {
    API.unsubscribeFromNewMessages(this.updateMessages);
  }

  render() {
    return (...);
  }
}

Now that we are at two behaviors, the component is starting to get a little large but it's not that bad. Notice though, that the highlights aren't near each other, and are actually starting to fracture.

Moving on, it's time to handle the document title. We can store the original document title, and update it if we get any new messages.

class Intercom extends Component {
  state = {
    newMessages: [],
    messages: [],
    originalDocumentTitle: document.title,
  };

  updateNewMessages = data => {
    this.setState({
      newMessages: [...data.messages, ...this.state.newMessages]
    });
  };

  componentDidMount() {
    API.getMessages(this.props.user.id, data =>
      this.setState({ messages: data.messages })
    );

    API.subscribeToNewMessages(this.updateMessages);
  }

  componentDidUpdate() {
    document.title = this.state.newMessages.length ?
      'New Messages' :
      this.state.originalDocumentTitle
  }

  componentWillUnmount() {
    API.unsubscribeFromNewMessages(this.updateMessages);
  }

  render() {
    return (...);
  }
}

Alright, now this file is starting to get a little big, and it's getting harder to see the big picture for each of the three behaviors.

If you've been working in React for awhile, you know that we already have techniques for dealing with this in a class component. If you don't know what to do though, you might keep adding behaviors and going into tech debt.

Hooks has in interesting effect on components by default. Take a look at what the above code would look like if written with hooks. I'll highlight the code related to the new messages behavior.

function Intercom(props) {
  /* Fetch old messages */
  const [messages, setMessages] = useState([]);
  useEffect(
    () => API.getMessages(props.user.id, setMessages),
    [props.user.id]
  );

  /* Watch for new ones */
  const [newMessages, setNewMessages] = useState([]);
  useEffect(
    () => {
      API.subscribeToNewMessages(props.user.id, setNewMessages);

      return () =>
        API.unsubscribeFromNewMessages(props.user.id, setNewMessages);
    },
    [props.user.id]
  );

  /* Update document title as needed */
  const [originalTitle] = useState(document.title);
  useEffect(
    () => {
      document.title = newMessages.length
        ? "You have new messages!"
        : originalTitle;
      return () => (document.title = originalTitle);
    },
    [newMessages.length]
  );

  return (...);
}

Everything is clumped together by behavior instead of by lifecycle hook. This makes the debugging and refactoring stories much shorter. You don't have to go from lifecycle hook to lifecycle hook plucking out bits of logic to move.

Now that we have these three clear bundles of logic, we can utilize Custom Hooks, and write our own hooks that abstract the behaviors away in a reusable way.

function useMessages(id) {
  const [messages, setMessages] = useState([]);
  useEffect(
    () => API.getMessages(props.user.id, setMessages),
    [id]
  );

  return messages;
}

function useNewMessages(id) {
  const [messages, setMessages] = useState([]);
  useEffect(
    () => {
      API.subscribeToNewMessages(id, setMessages);

      return () =>
        API.unsubscribeFromNewMessages(id, setMessages);
    },
    [id]
  );

  return messages;
}

function useTemporaryDocumentTitle(temporary) {
  const [original] = useState(document.title);
  useEffect(
    () => {
      document.title = temporary || original;
      return () => document.title = original;
    },
    [temporary]
  );
}

We can import those Custom Hooks into our component, and now our previously complicated Intercom component looks like this:

function Intercom(props) {
  const messages = useMessages(props.user.id);
  const newMessages = useNewMessages(props.user.id);
  useTemporaryDocumentTitle(
    newMessages.length ? "You have new messages!" : null
  )

  return (...);
}

So hooks can help us put behaviors into a reusable box, but did you know that we've been doing that already? We've slowly evolved over time because each technique that's been found has had some problems.

Let's take a look at each one, examine their trade-offs, and think about what could be done to improve.

Mixins

Mixins get a lot of flak. They set the stage for grouping together lifecycle hooks to describe one effect.

const NewMessagesMixin = {
  getInitialState() {
    return {
      newMessages: []
    }
  },

  updateNewMessages(data) {
    this.setState({
      newMessages: [...data.messages, ...this.state.newMessages]
    });
  };

  componentDidMount() {
    API.subscribeToNewMessages(this.updateMessages);
  }

  componentWillUnmount() {
    API.unsubscribeFromNewMessage(this.updateMessages)
  }
}

const Intercom = React.createClass({
  mixins: [NewMessagesMixin, MessagesMixin, DocumentTitleMixin],

  /* Rest of our component would go here! */
})

While the general idea of encapsulating logic is great, we ended up learning some serious lessons from mixins.

It's not obvious where this.state.newMessages is coming from. With mixins, it's also possible for the mixin to be blindly relying on that a property exists in the component.

That becomes a huge problem as people start including and extending tons of mixins. You can't simply search in a single file and assume you haven't broken something somewhere else.

Also, you can't easily use this.state.newMessages in another mixin. They don't compose, so you can't plug it into other encapsulations.

Refactoring needs to be easy. These mixed-in behaviors need to be more obvious that they don't belong to the component. They shouldn't be using the internals of the component. 🙅‍

Mixins are also very difficult to type and test, which makes them harder to work with in an environment optimized for change.

Higher Order Components

We can achieve a similar effect, and make it a bit less magical by creating a container that passes in props! Inheritance's main trade-off is it makes refactoring harder, so let's try composition!

/* Function that takes a component and returns a component! */
function withNewMessages(Component){
  return class withNewMessage extends Component {
    state = { newMessages: [] }

    updateNewMessages = data => {
      this.setState({
        newMessages: [...data.messages, ...this.state.newMessages]
      });

      componentDidMount() {
        API.subscribeToNewMessages(this.updateMessages);
      }

      componentWillUnmount() {
        API.unsubscribeFromNewMessage(this.updateMessages)
      }

      render() {
        return (<Component {...this.props} {...this.state} />)
      }
    };
  }
}

class Intercom extends Component {
  /* Component that uses newMessage, messages props*/
}

const DecoratedIntercom = withNewMessages(
  withMessages(
    withDocumentTitle(
      Intercom
    )
  )
)

While this is more code, we are moving in the right direction. We have all the benefits of Mixins. Now we have an <Intercom /> component that is no longer tightly coupled to the subscription behavior.

Testing has become easier, typing still isn't quite as powerful as it could be though. They can compose together, but there could still be namespace collisions in the props.

Render Props & Children as a Function

This is the pattern that has been staring us in the face the entire time. All we want is a component that handles the subscribe to new messages behavior, and the ability to render whatever we want.

class NewMessages extends Component {
  state = { newMessages: [], }

  updateNewMessages = data => {
    this.setState({
      newMessages: [...data.messages, ...this.state.newMessages]
    });
  }

  componentDidMount() {
    API.subscribeToNewMessages(this.updateMessages);
  }

  componentWillUnmount() {
    API.unsubscribeFromNewMessage(this.updateMessages)
  }

  render() {
    return this.props.children(this.state)
  }
}

class Intercom extends Component {
  render() {
    <NewMessages>
      {({ newMessages, }) => (
        // Write code that uses them here!
      )}
    </NewMessages>
  }
}

This subtle difference has some pretty awesome benefits

It is now super obvious what is providing newMessages. You can also easily rename them to prevent name collisions.
We have flexible control over what is rendering. We don't need to be making new components, and if we decide to, it's just a simple copy paste.
You can see all of this directly in a components render function. It's in plain sight and easy for new developers coming in to identify. cmd + f checks out here.

However, it creates a false sense of hierarchy. Just because a behavior is "nested" under another behavior doesn't mean it relies on the parent behavior.

Also it's such a pain to refactor when you have to add or remove a behavior. Good luck refactoring something that looks like this:

const MyForm = () => (
  <DataFetcher>
    {({ data, }) => (
      <Actions>
        {({ actions, }) => (
          <Translations>
            {({ translations, }) => {
              <Theme>
                {({ theme, }) => (
                  <form styles={theme.form}>
                    <input type="text" value={data.value} />
                    <button onClick={actions.submit}>
                      {translations.submit}
                    </button>
                  </form>
                )}
              </Theme>
            }}
          </Translations>
        )}
      </Actions>
    )}
  </DataFetcher>
)

Things to Remember with Hooks

When using hooks, you have to remember a couple of rules that may seem weird at first:

⚠️ You should call hooks at the top level of the render function.

This means no conditional hooks. Our contract with React is that we will call the same amount of hooks, in the same order every time.

This rule starts to make more sense when you compare it to how Mixins, and HOCs work. You can't conditionally use them and reorder them on each render.

If you want conditional effects, you should split your hooks into other components, or consider a different pattern.

⚠️ You can only use hooks in React Function Components, and in Custom Hooks.

I'm not sure if there's actually any technical reason to not try calling them in a regular function. This ensures that the data is always visible in the component file.

⚠️ There aren't hook primitives for componentDidCatch or getSnapshotBeforeUpdate.

The React team says they are on their way though!

For the componentDidCatch use case, you could create an Error Boundary component, getSnapshotBeforeUpdate is a bit trickier, but fortunately pretty rare.

Some Final Notes

I have no doubt that hooks are about to change the way we view React, and shake up some best practices. The amount of excitement and libraries coming out is inspiring!

However, I have seen the hype for all of these design patterns in the past. While most have ended up being very valuable tools in our toolboxes, they all come with a price.

I still don't fully understand the trade-offs of hooks, and that scares me. I highly suggest playing around with them, and learning by example. You should probably wait a bit before doing a full rewrite in them though 😉

If you have any questions or are looking for one-on-one React mentorship, feel free to tweet me @yurkaninryan any time!

Good luck and happy coding!! 😄

Let's fall in love with React Fiber

Ryan Yurkanin — Tue, 22 Jan 2019 13:46:41 +0000

TLDR, React Fiber is an internal engine change that allows React to break the limits of the call stack. It's creation enables React to pause/start rendering work at will. Eventually, React users will be able to hint at the "priority" of work.

Currently, we can't directly interface with it, so why should we care about it? Because it's really freaking cool!

React before Fiber was like working at a fast paced company without git.

Imagine being in the middle of a huge feature, and your boss needs a hotfix, pronto. You can't stop working though because all your changes are in one file, you're committed to finishing this work.

If we were using git, we would be able to commit our work to a branch, and switch to a quick hotfix branch.

With Fiber, React can pause and resume work at will to get working on what matters as soon as possible! 🎉

React Internals in a nutshell 🥜

You create a tree of components. React takes this tree, walks through it, and creates a virtual model of the end result. Perhaps you are rendering to the DOM, perhaps you are targeting native. At this point, that doesn't matter to React.

If you've never used React, here's an example of a tree of components.

Now, as your app updates, React will do that process of creating the virtual result over and over again. Each time, it compares the previous virtual tree to the next one.

At this point, we get platform-dependent. If you are rendering to the DOM, it could be that only one class on one element changed. React will walk through the virtual tree, find what's changed, and update as little as it can.

This could mean updating one class attribute, or it could mean tearing down the whole DOM. This is Reconciliation.

Before Fiber, this was it. The work was laid out, and the renderer of choice got to work. Even if the browser was lagging, the user was typing, or the planet was about to explode, the render train wouldn't stop. 🚋

How does it work (at a high level)?

With Fiber, there are now varying levels of priority for updates. Updating an input a user is typing into has higher priority than a list with thousands of components.

Fiber breaks tree computation into units of work that it can "commit" at any time. So what is a unit of work? It's simply a node in your component tree!

React can now pause, resume, and restart work on a component. This means certain lifecycle hooks may fire more than once.
React can have a priority-based update system. This allows the React Team to fine tune the renderer so that React is fastest during the most common use cases.

I want to focus on that first point a bit, though. React is going to be moving away from (but still supporting!) some old lifecycle hooks, and adding some new ones! 🚀

componentWillMount, componentWillUpdate, componentWillReceiveProps, can now fire multiple times. You shouldn't trigger side effects here.

Now, you want to fire side effects in the lifecycle hooks that will only fire once: componentDidMount and componentDidUpdate

To make up for a lot of the use cases that componentWillReceiveProps covered, we will be receiving two new hooks.

getDerivedStateFromProps which doesn't have access to previous props or the component instance, but allows you to sync state with your props.
getSnapshotBeforeUpdate gives you access to the DOM before it gets updated. The value you return is usable in componentDidUpdate.

Here is a graph illustrating how the lifecycle hooks work with React Fiber

As of React 16.4, getDerivedStateFromProps now always fires before the render method. Not just when props update!

If you have any questions or are looking for one-on-one React mentorship, feel free to tweet me @yurkaninryan any time!

Good luck and happy coding! 😌👌

DEV Community: Ryan Yurkanin

Algebraic Effects Help Us Optimize for Change

Good Architecture Helps Codebases and Developers Scale

Learning from Try/Catch

How Does This Help Optimize for Change?

Wrapping Up

Understanding Reducers: You Can Use Them Without Redux

🤔 What is a Reducer?

💩 Creating a ~Worse~ "Different" Version of Redux

💡 Reducers Are Useful for More Than State

🏆 Summing It Up

Why React Hooks, and how did we even get here?

Mixins

Higher Order Components

Render Props & Children as a Function

Things to Remember with Hooks

Some Final Notes

Let's fall in love with React Fiber

React before Fiber was like working at a fast paced company without git.

React Internals in a nutshell 🥜

How does it work (at a high level)?

Learning from `Try/Catch`