Forem: Andy Van Slaars

Maintain Multiple VSCode Configurations

Andy Van Slaars — Wed, 09 Mar 2022 01:44:35 +0000

I split my time in VSCode between writing code and presenting programming lessons. Because of this, I need to maintain multiple configurations. One has all the settings and extensions I find useful for getting code written. The other is focused on sharing with others. It has higher contrast, larger fonts, and disables settings that could be distracting for an audience.

Manually changing your configurations can be tedious, inconsistent, and error prone. In this article, we'll look at what it takes to create and use multiple VSCode configurations.

Initial Setup

All we need to do to create a distinct setup is start an instance of VSCode that stores user data and extensions in a non-default location.

Once we have settings stored in this new location, we'll have the option to open VSCode using either the default options or this set of distinct options.

First make sure you have the VSCode terminal commands installed.

You can do this from VSCode by launching the command palette (cmd + shift + P on mac), typing "shell command", and selecting the "Shell Command: Install 'code' command in PATH" option.

We'll start by creating a parent directory to hold all of our non-default profiles. I'll call this code_profiles and put it in my home directory (~/).

mkdir ~/code_profiles

With that created, I'll move into that new directory.

cd ~/code_profiles

And now we need to launch VSCode and specify new directories for extensions and user data. To do this, we'll open VSCode from the terminal and pass in the --extensions-dir and --user-data-dir flags.

code --extensions-dir ./presentations/exts --user-data-dir ./presentations/data

For this example, I'm creating a profile specifically for presenting, so I'm asking VSCode to put user data and extensions in subdirectories of a shared presentations directory.

From here, you can install extensions and update settings as appropriate for how you'll use this profile. For presentations, I'll bump up the font size, choose a theme with good contrast and install extensions that make it easy to quickly parse the code on screen, like this indent rainbow extension, for example.

You don't have to get it all setup at once. You can continue to add extensions and change settings anytime you run VSCode with these directories specified.

Setup an Alias

In order to use VSCode with your new settings, you need to open VSCode with the same command we used earlier.

code --extensions-dir ./presentations/exts --user-data-dir ./presentations/data

This works, but it isn't the most convenient approach, especially if you use this approach to create several profiles for different needs.

To make this easier for ourselves, we'll create an alias for our shell. I use ZSH, so my alias will go in my ~/.zshrc file. Yours may need to go into your bashrc or bash_profile.

I'll create an alias, ensuring to target the directory using a path that includes my home directory (~/) so I can run this from anywhere.

# ~/.zshrc (or bashrc, or bash_profile, etc)

alias present="code --extensions-dir ~/code_profiles/presentations/exts --user-data-dir ~/code_profiles/presentations/data"

Once you've created your alias you can restart your terminal, or reload your profile with source ~/.zshrc (or bashrc, bash_profile, etc.).

With this alias in place, we can navigate to a project directory like cd ~/projects/my-awesome-blog, and then run present . and your project will be opened in VSCode with your presentation settings applied.

Conclusion

Now you have the ability to maintain 2 distinct configurations for VSCode. You can continue to install and update extensions and tweak settings while maintaining these distinct configurations. If you want or need to customize your environment for even more specific uses, you can just follow the same process and create additional configurations with their own aliases for convenience.

If learning with video is your thing, I created a video lesson on this topic on egghead.io.

Create a Card Flip Animation with CSS

Andy Van Slaars — Mon, 07 Mar 2022 17:09:09 +0000

Animation, when used with restraint, can be a great way to enhance a user experience by making elements on the page feel more tangible and by adding visual interest. In this short tutorial, we'll use HTML, CSS, and just a touch of JavaScript to animate a card flipping over.

We'll be building up to the example in this CodeSandbox. Clicking the "Flip Card" button will show the opposite side of the card and do so with a nice, natural looking flip.

You can follow along with live examples embedded right in the article at the original source.

Initial Setup

Our card will consist of a pair of divs, we'll toggle between which div we want to show using a single CSS class, and we'll do the rest using CSS transforms. Let's setup our divs and initial CSS to get started.

Markup

<body>
<div class="container">
  <button type="button" id="flip-btn">Flip Card</button>
  <div class="card">
    <div id="back" class="cardBack">Back</div>
    <div id="front" class="cardFront">Front</div>
  </div>
</div>
</body>

Initial Styles

Let's start by giving our elements their basic styling.

Container

This element will wrap the entire example, so we'll make it take up the whole view port and throw a light gray background on it. We'll also give it a little padding, make it a flex container, set our flex direction to columns, and center everything.

.container {
  padding: 20px;
  background-color: lightgray;
  display: flex;
  flex-direction: column;
  align-items: center;
  margin: auto;
  min-height: 100vh;
}

Card Wrapper

Looking at the markup, we can see that this div wraps the two divs that represent the front and back of our card. We'll set a width, minimum height, and a position: relative. We'll ultimately end up setting our front and back card divs to use position: absolute. By putting the relative here, we make sure that absolute positioning is applied relative to this div.

.card {
  margin-top: 1rem;
  min-height: 300px;
  width: 250px;
  position: relative;
  border-radius: 0.25rem;
}

Front and Back Cards

The front and back card divs will share quite a bit of their styling, so let's start with the shared styling. We're setting the box-sizing property to border-box to make sure that however we style the cards, their width and height includes any borders or padding and they fit within the parent element's width. We'll also round the corners and apply a box shadow to provide a bit of depth.

.cardFront,
.cardBack {
  box-sizing: border-box;
  border-radius: 0.25rem;
  height: 100%;
  padding-left: 0.5rem;
  padding-right: 0.5rem;
  box-shadow: 0 4px 6px -1px rgba(0, 0, 0, 0.1),
    0 2px 4px -1px rgba(0, 0, 0, 0.06);
  width: 100%;
}

Toggle Classes with JavaScript

We don't need a framework or build tools here, in fact, there's such a small amount of JavaScript here that we'll just add it in script tags right in the HTML file. Of course, you can make this happen in your favorite framework. For this demo, let's keep it simple and add the following script tags to your HTML file. I added mine right after the closing div for our container.

<script>
  const front = document.getElementById('front')
  const back = document.getElementById('back')
  const btn = document.getElementById('flip-btn')
  function handleFlip() {
    front.classList.toggle('flipped')
    back.classList.toggle('flipped')
  }
  btn.addEventListener('click', handleFlip)
</script>

We're going to use the flipped class on both front and back divs and we'll control the styling through that. This code uses browser APIs to add and remove the flipped class to the divs when the button is clicked.

Transform Cards Based on The `flipped` Class

Now that we have the flipped class being toggled on our divs, let's add some styles that are specific to the front and back cards, accounting for the flipped and non-flipped states.

Card Back Styling

We'll give the back card a background color, and then we'll use a transform to set an initial rotation. We're turning the card 180deg on the Y axis, flipping it over by default. Then when the flipped class is applied, we use the same rotateY function and flip the card to face us.

.cardBack {
  transform: rotateY(180deg);
  background-color: #ebf4ff;
}

.cardBack.flipped {
  transform: rotateY(0deg);
}

Front Card Styling

We'll apply the same flipping behavior to the front card, but in reverse. We'll default to the card facing us, and rotate it 180deg when the flipped class is applied.

.cardFront {
  transform: rotateY(0deg);
}

.cardFront.flipped {
  transform: rotateY(180deg);
}

Add the Flip with CSS Transitions

With our logic in place to toggle our classes, and our transforms applied, we can observe the card sections applying the updated styles and "flipping". It's quite abrupt in its current state, so let's add a transition rule to our shared card styles. We'll add transition: transform 0.5s ease; to transition our tranforms over half a second, and we'll apply the ease timing function.

.cardFront,
.cardBack {
  box-sizing: border-box;
  border-radius: 0.25rem;
  height: 100%;
  padding-left: 0.5rem;
  padding-right: 0.5rem;
  box-shadow: 0 4px 6px -1px rgba(0, 0, 0, 0.1),
    0 2px 4px -1px rgba(0, 0, 0, 0.06);
  width: 100%;
+ transition: transform 0.5s ease;
}

With that applied, we have a nice animated transition when flipped.

Position Cards

Now we should position the cards so they behave like a single card instead of two stacked divs. Our parent container has a position: relative rule applied to it, so all we need to do is set a rule for each card element to position: absolute. Now our cards will be absolutely positioned, relative to the parent container. Our card pieces are sitting on top of one another now.

.cardFront,
.cardBack {
  box-sizing: border-box;
  border-radius: 0.25rem;
  height: 100%;
  padding-left: 0.5rem;
  padding-right: 0.5rem;
  box-shadow: 0 4px 6px -1px rgba(0, 0, 0, 0.1),
    0 2px 4px -1px rgba(0, 0, 0, 0.06);
  width: 100%;
  transition: transform 0.5s ease;
+ position: absolute;
}

Hide the Back Side of Cards

When we flip our cards, we can still see both labels. This is because we only have a background color set on the back card, and the stacking order puts the front card on top, so we see both labels in their respective position and rotation based on that state of the flipped class.

Let's update our styling to hide the back side of the cards so we only see the card that is face up. We'll do this by adding a backface-visibility rule to our shared styles:

.cardFront,
.cardBack {
  box-sizing: border-box;
  border-radius: 0.25rem;
  height: 100%;
  padding-left: 0.5rem;
  padding-right: 0.5rem;
  box-shadow: 0 4px 6px -1px rgba(0, 0, 0, 0.1),
    0 2px 4px -1px rgba(0, 0, 0, 0.06);
  width: 100%;
  transition: transform 0.5s ease;
  position: absolute;
+ backface-visibility: hidden;
}

Now when we flip the cards, we only see the face up card. Notice that when we can see the front card, we lose the background color that we had applied to the back card because it is hidden. We'll add a background to the front card in a future, cleanup step. For now we'll keep it so everything is clear in the UI as we progress.

We're almost done. The flip animation probably looks a little strange and unnatural at this stage. That's okay, we'll address that next.

Fix the Unnatural Flip

Perspective

To make this animation feel more natural, we'll apply some perspective to give the card a feeling of depth. I've settled on 600px here, but feel free to play around with the values and pick something that feels "right" to you.

.cardBack {
-  transform: rotateY(180deg);
+  transform: perspective(600px) rotateY(180deg);
   background-color: #ebf4ff;
}

.cardBack.flipped {
-  transform: rotateY(0deg);
+  transform: perspective(600px) rotateY(0deg);
}

.cardFront {
-  transform: rotateY(0deg);
+  transform: perspective(600px) rotateY(0deg);
}

.cardFront.flipped {
-  transform: rotateY(180deg);
+  transform: perspective(600px) rotateY(180deg);
}

Rotation Direction

Something is still off, our card flip still doesn't feel right. The remaining problem is the direction the cards flip in. They're essentially crashing through each other to swap rotations. We need them to rotate as a single unit, so we'll have to make one of the cards go in the opposite direction.

As it turns out, the transition algorithm will do some math and you can manipulate that math to control the direction the object moves in when transitioning. All we need to do is change our front card from 180deg when flipped to -180deg. It doesn't change the end result, but it does change the way the transition is applied.

.cardFront.flipped {
-  transform: perspective(600px) rotateY(180deg);
+  transform: perspective(600px) rotateY(-180deg);
}

Final cleanup

All we have left is to apply a background color to the front card so our card isn't transparent from the front. You can do whatever you want in terms of color, background image, etc. Here we'll keep it simple and just apply the same background to both cards by moving our background-color rule from the cardBack-specific rules to our shared card styles.

.cardFront,
.cardBack {
  box-sizing: border-box;
  border-radius: 0.25rem;
  height: 100%;
  padding-left: 0.5rem;
  padding-right: 0.5rem;
  box-shadow: 0 4px 6px -1px rgba(0, 0, 0, 0.1),
    0 2px 4px -1px rgba(0, 0, 0, 0.06);
  width: 100%;
  transition: transform 0.5s ease;
  position: absolute;
  backface-visibility: hidden;
+ background-color: #ebf4ff;
}

.cardBack {
- background-color: #ebf4ff;
  transform: perspective(600px) rotateY(180deg);
}

Conclusion

This is a pretty common interaction to animate and CSS makes it fairly simple to achieve. No need to complicate things with too much JavaScript. By using CSS for this, all the tricky logic and things we might have otherwise missed are handled for us by the browser. For example, if we toggle the flipped class part way through a transition, it naturally changes direction without any jarring flickers or jumps. It just picks up the new value calculations from where you left off. Go ahead, click the flip buttons a whole bunch of times really fast... the card will flip flop and finish as expected without awkwardly jumping to the far end of the animation at any point. This is absolutely something that we could build with JavaScript, but not necessarily something we should build with JavaScript. By using a CSS based approach, we cut down our initial work, reduce the need for maintenance, and gain some performance by letting the browser handle this for us.

BTW, If you like to learn with bite-sized videos, I published this very thing as a lesson on egghead.io a while back, check it out!

Don't DRY your tests 🌵🏜🦂

Andy Van Slaars — Sun, 28 Jul 2019 19:47:55 +0000

For me, tests provide 3 major benefits (in this order):

As the first consumers of your code (at least when following TDD), tests are a great way to inform decisions around the public API for your code.
Tests are living documentation for your code. Unlike written documentation (also important) or code comments, tests are guaranteed to be in sync with your code if they're passing.
A solid suite of tests is a great safety net for catching unintended breaking changes when refactoring your code and adding features.

The problem

A lot of developers hear, DRY (Don't Repeat Yourself) and apply the concept to code duplication rather than it's intended target, knowledge duplication. This often leads to overly complex code, aimed at removing a handful of characters that just happen to be the same shape if you squint hard enough.

Each of your tests should stand on its own. Your tests should be isolated and free of side-effects so they are not order-dependent and one test can't create side-effects that lead to false positives (or negatives) in other tests.

When people try to "DRY out" their tests, this leads to tests that rely on a lot of shared utility functions and values stored in a surrounding scope aimed at cutting down on duplication. This leads to a lot of indirection and opens up the door to unintended side-effects that are hard to see and can be frustrating to debug.

In addition to the potential issues with side-effects, all the indirection makes it harder to maintain your test code in the long run and hurts the overall readability of individual tests. If you can't look at a test and understand what is being tested and the intended use of the code under test, it's really not living up to it potential as live documentation. It's also hard to write tests in this way and have them inform API decisions, since you up being scattering the code implementation throughout your test test utilities and you don't directly use the code as a consumer would in your test.

The solution

Don't DRY your tests!

Instead, you might consider leaning towards Write Everything Twice (WET), or in the case of your tests... as many times as you need to.

Let's look at an example

First, to set a little context, this is a test for a React component and the project is configured to use Jest, Testing Library and jest-dom for extending Jest's matchers to include toBeInTheDocument.

it('should correctly apply the testId', () => {
  const testId = 'test-id'
  const { getByTestId } = renderBasicButton({ testId })

  expect(getByTestId(testId)).toBeInTheDocument()
})

So what's happening here? Let's start with what we can determine from these 3 lines of test code:

This test is rendering a "Basic" button, using a function called renderBasicButton that must be defined somewhere in the test's surrounding scope
That renderBasicButton function accepts an object that can have a testId property
It uses the getByTestId function provided as part of the object returned from renderBasicButton to check that the element can be found in the document.

Based on the test description, some knowledge of the libraries used here, and the things we were able to surmise from the code itself, it's not a stretch to imagine what's happening here:

renderBasicButton must use testing-library's render function under the hood, this is where getByTestId is coming from. This isn't a given, but it seems logical if you're familiar with testing-library.
It must render a button and apply the testId value to the data-testid attribute on the resulting button element. This also assumes knowledge of testing-library.

Now, before we go an look at the code that supports this test, let's list out the questions we still have:

What else happens when the button is rendered?
- Does it get other props?
- Does it have any children?
- Do those things even matter for this test?
- If someone changes something inside that renderBasicButton function, will this test start failing?
We're pretty sure it's returning an object that includes functions returned from testing-library's render function.
- Is it directly returning that?
- Is it returning a subset of that?
- Is it augmenting that return value and returning a superset of that?

Let's take a look at the renderBasicButton function and see if we can answer these questions

const renderBasicButton = (myProps = {}) => {
  const props = {
    ...BASE_BUTTON_PROPS,
    ...myProps,
  }

  return render(<Button {...props}>{TEXT}</Button>)
}

Now we're getting somewhere. We can answer some of our questions now:

This does in-fact use render under the hood and directly returns that result. No subset or superset.
We can also see that whatever I pass in that object argument is merged with BASE_BUTTON_PROPS to create the props that are spread into the Button component.
The Button component is being rendered with TEXT as children

So we're one step removed from the test code, and the picture is coming into focus, but it still isn't 100% clear. We have some values coming in from the surrounding scope, so let's look at TEXT and BASE_BUTTON_PROPS to see what's actually being rendered in the test.

const TEXT = 'Test Text'

const BASE_BUTTON_PROPS = {
  id: 'testId',
  onClick: jest.fn(),
}

Now we know that TEXT is just a string, so nothing more than you'd expect in a "basic" button. And BASE_BUTTON_PROPS provides an id and an onClick that uses a spy function from Jest.

Now that I have all the pieces, I can reconstruct the button that gets rendered in this test. If I were to write out the JSX for it, it would look like:

<Button onClick={jest.fn()} id="testId" testId="test-id">
  Test Text
</Button>

Now that we know what that the resulting JSX would be, we can revise the test to just use the render function from RTL directly:

it('should correctly apply the testId', () => {
  const testId = 'test-id'
  const { getByTestId } = render(
    <Button onClick={jest.fn()} id="testId" testId={testId}>
      Test Text
    </Button>
  )

  expect(getByTestId(testId)).toBeInTheDocument()
})

I've kept the testId variable to avoid potential errors from duplicating that string value, but it's right in the test along with everything else, so you don't have to go anywhere else in the code to see that value.

This is better, but we can still do a little bit better. Since we're ultimately just verifying that the testId prop is correctly rendered to the DOM as data-testid, we don't really need this button to have an id value or a click handler. Let's remove the props that aren't required for this test:

it('should correctly apply the testId', () => {
  const testId = 'test-id'
  const { getByTestId } = render(<Button testId="test-id">Test Text</Button>)

  expect(getByTestId(testId)).toBeInTheDocument()
})

We don't really need the text here either, but a button with no content isn't a great example of usage, but I don't want it to distract from the primary point of the test, so let's make it a little more subtle:

it('should correctly apply the testId', () => {
  const testId = 'test-id'
  const { getByTestId } = render(<Button testId="test-id">click</Button>)

  expect(getByTestId(testId)).toBeInTheDocument()
})

I think by using the shorter, all-lowercase string here, we've minimized its visual appearance, making it easier to focus on the important bits of the test code.

You could easily argue that it isn't worth it, or that the text isn't what's being tested so it could be removed. I could go either way on this and don't have a strong opinion either way.

What have we gained?

Reduced cognitive load

By putting all the relevant bits of our test inside the test function, we've made it easier to see what is being tested, what props are important for this particular test, and what the consuming code for this component would look like, albeit, an incomplete code snippet. It was possible to piece this all together in our original test, but it required us to jump around the code to gather all the information we need.

Clear signals of intent

We've removed bits of irrelevant code and made it clear that the id and onClick props have nothing to do with the testId. If all of our tests reveal only the important bits of code, a test that has multiple props on the button will signal that all the included bits are related to that test. In a more complex scenario, you very well may have mocks that are important for the functionality under test, when you define their behavior right in your test, it makes the impact of side-effects in your code clear without you having to track that mock logic down. If the behavior for those mocks were defined elsewhere, you could easily miss them. On the flip side, if a mock is required for your code to work, but isn't part of the intended test, you can signal if a mock is unimportant by giving it a generic value, like resolving a mock service with an empty array, object for a string default, depending on what that service should return

Simplified test code maintenance

If the feature under test here changes in the future, we have a single place to go and make changes. If we no longer need the feature in the future, we can delete this test and be confident that we aren't leaving behind orphaned utility functions. Sure, a linter could catch this for us, but I thought it was worth mentioning as a nice bonus feature of this approach.

Of course, a lot of this can be very subjective, but I've found in my experience that when I'm coming into a new code base with tests, the more "DRY" a test suite is, the harder it is for me to parse. I spend more time piecing things together than I do in cases where tests are self-contained.

If faced with the choice between duplicating code across tests and creating abstractions for that test code, consider the implications that will have for new team members, or even the current team members when you've forgotten about some of the nuance in a section of your code. If you have clear, easily parsable tests, you'll be grateful for the reduced cognitive load required to understand the code and tests.

Immutable Deep State Updates in React with Ramda.js

Andy Van Slaars — Sun, 09 Jul 2017 01:48:42 +0000

Basic state updates in React are a breeze using setState, but updating deeply nested values in your state can get a little tricky. In this post, I'm going to show you how you can leverage lenses in Ramda to handle deep state updates in a clean and functional way.

Let's start with a simple counter component.

import React from 'react';
import { render } from 'react-dom';

class App extends React.Component {
  constructor(props) {
    super(props)
    this.state = {
      count: 0
    }
    this.increase = this.increase.bind(this)
    this.decrease = this.decrease.bind(this)
  }

  increase() {
    this.setState((state) => ({count: state.count + 1}))
  }

  decrease() {
    this.setState((state) => ({count: state.count - 1}))
  }

  render() {
    return (
      <div>
        <button onClick={this.increase}>+</button>
        <div>
          {this.state.count}
        </div>
        <button onClick={this.decrease}>-</button>
      </div>
    )
  }
}

render(<App />, document.getElementById('root'));

Here, we're using a function as the argument for setState and just incrementing or decrementing the count based on the passed in state value. This is fine for a simple property sitting at the top level of the state tree, but let's update the shape of our state object and move that count a little deeper into the state.

this.state = {
  a: {
    name: 'pointless structure',
    b : {
      stuff: 'things',
      count: 0
    }
  }
}

This new state is incredibly contrived, but it'll help illustrate the point. Now, in order to update the count, we need to update property a, which in turn needs an updated b and that will contain our updated count. The update function for increase will now need to look like this:

increase() {
  this.setState((state) => ({a: {...state.a, b: {...state.a.b, count: state.a.b.count + 1}} }))
}

This works, but is not very readable. Let's briefly look at what's happening here.

The existing state is passed into the function, and we want to return an object that represents the object to be merged with state. The setState method doesn't merge recursively, so doing something like this.setState((state) => ({a: {b:{ count: state.a.b.count + 1}}})) would update the count, but the other properties on a and b would be lost. In order to prevent that, the returned object is created by spreading the existing properties of state.a into a new object where we then replace b. Since b also has properties that we want to keep, but don't want to change, we spread state.b's props and replace just count, which is replaced with a new value based on the value in state.a.b.count.

Of course, we need to do the same thing with decrease, so now the entire component looks like this:

import React from 'react';
import { render } from 'react-dom';

class App extends React.Component {
  constructor(props) {
    super(props)
    this.state = {
      a: {
        name: 'pointless structure',
        b : {
          stuff: 'things',
          count: 0
        }
      }
    }
    this.increase = this.increase.bind(this)
    this.decrease = this.decrease.bind(this)
  }

  increase() {
    this.setState((state) => ({a: {...state.a, b: {...state.a.b, count: state.a.b.count + 1}} }))
  }

  decrease() {
    this.setState((state) => ({a: {...state.a, b: {...state.a.b, count: state.a.b.count - 1}} }))
  }

  render() {
    return (
      <div>
        <h1>{this.state.a.name}</h1>
        <h2>{this.state.a.b.stuff}</h2>
        <button onClick={this.increase}>+</button>
        <div>
          {this.state.a.b.count}
        </div>
        <button onClick={this.decrease}>-</button>
      </div>
    )
  }
}

render(<App />, document.getElementById('root'));

Those setState calls are kind of a mess! The good news is, there's a better way. Lenses are going to help us clean this up and get back to state updates that are both readable and clearly communicate the intent of the update.

Lenses allow you to take an object and "peer into it", or "focus on" a particular property of that object. You can do this by specifying a path to put your focus on a property that is deeply nested inside the object. With that lens focused on your target, you can then set new values on that property without losing the context of the surrounding object.

To create a lens that focuses on the count property in our state, we will use ramda's lensPath function and array that describes the path to count, like so:

import {lensPath} from 'ramda'

const countLens = lensPath(['a', 'b', 'count'])

Now that we have a lens, we can use it with one of the lens-consuming functions available in ramda: view, set and over. If we run view, passing it our lens and the state object, we'll get back the value of count.

import {lensPath, view} from 'ramda'
const countLens = lensPath(['a', 'b', 'count'])
// somewhere with access to the component's state
view(countLens, state) // 0

Admittedly, view doesn't seem super useful since we could have just referenced the path to state.a.b.count or use ramda's path function. Let's see how we can do something useful with our lens. For that, we're going to use the set function.

import {lensPath, view, set} from 'ramda'
const countLens = lensPath(['a', 'b', 'count'])
// somewhere with access to the component's state
const newValue = 20
set(countLens, newValue, state)

When we do this, we'll get back an object that looks like:

{
  a: {
    name: 'pointless structure',
    b : {
      stuff: 'things',
      count: 20 // update in context
    }
  }
}

We've gotten back a new version of our state object in which the value of state.a.b.count has been replaced with 20. So not only have we made a targeted change deep in the object structure, we did it in an immutable way!

So if we take what we've learned so far, we can update our increment method in our component to look more like this:

increase() {
    this.setState((state) => {
      const currentCount = view(countLens, state)
      return set(countLens, currentCount+1, state)
    })
  }

We've used view with our lens to get the current value, and then called set to update the value based on the old value and return a brand new version of our entire state.

We can take this a step further. The over function takes a lens and a function to apply to the target of the lens. The result of the function is then assigned as the value of that target in the returned object. So we can use ramda's inc function to increment a number. So now we can make the increase method look like:

increase() {
    this.setState((state) => over(countLens, inc, state))
  }

Pretty cool, right?! Well, it gets even better... no, for real, it does!

All of ramda's functions are automatically curried, so if we pass over just the first argument, we get back a new function that expects the second and third arguments. If I pass it the first two arguments, it returns a function that expects the last argument. So that means that I can do this:

increase() {
    this.setState((state) => over(countLens, inc)(state))
  }

Where the initial call to over returns a function that accepts state. Well, setState accepts a function that accepts state as an argument, so now I can shorten the whole thing down to:

increase() {
    this.setState(over(countLens, inc))
  }

And if this doesn't convey enough meaning for you, you can move that over function out of the component and give it a nice meaningful name:

// outside of the component:
const increaseCount = over(countLens, inc)

// Back in the component
increase() {
    this.setState(increaseCount)
  }

And of course, the same can be done to the decrease method using dec from ramda. This would make the whole setup for this component look like this:

import React from 'react';
import { render } from 'react-dom';
import {inc, dec, lensPath, over} from 'ramda'

const countLens = lensPath(['a', 'b', 'count'])
const increaseCount = over(countLens, inc)
const decreaseCount = over(countLens, dec)

class App extends React.Component {
  constructor(props) {
    super(props)
    this.state = {
      a: {
        name: 'pointless structure',
        b : {
          stuff: 'things',
          count: 0
        }
      }
    }
    this.increase = this.increase.bind(this)
    this.decrease = this.decrease.bind(this)
  }

  increase() {
    this.setState(increaseCount)
  }

  decrease() {
    this.setState(decreaseCount)
  }

  render() {
    return (
      <div>
        <h1>{this.state.a.name}</h1>
        <h2>{this.state.a.b.stuff}</h2>
        <button onClick={this.increase}>+</button>
        <div>
          {this.state.a.b.count}
        </div>
        <button onClick={this.decrease}>-</button>
      </div>
    )
  }
}

render(<App />, document.getElementById('root'));

The nice thing here is that if the shape of the state changes, we can update our state manipulation logic just by adjusting the lensPath. In fact, we could even use the lens along with view to display our data in render and then we could rely on that lensPath to handle all of our references to count!

So that would mean this: {this.state.a.b.count} would be replaced by the result of: view(countLens, this.state) in the render method.

So here it is with that final adjustment, take it for a spin and see what you can do with it!

Hi, I'm Andy Van Slaars

Andy Van Slaars — Sun, 09 Jul 2017 00:46:30 +0000

I have been coding for 18 years.

You can find me on GitHub as avanslaars

I live in South Jersey, about 20 minutes from Philadelphia.

I work for Elsevier

I mostly program in these languages: JavaScript.

I am currently learning more about GraphQL.

Nice to meet you.

Forem: Andy Van Slaars

Maintain Multiple VSCode Configurations

Initial Setup

Setup an Alias

Conclusion

Create a Card Flip Animation with CSS

Initial Setup

Markup

Initial Styles

Container

Card Wrapper

Front and Back Cards

Toggle Classes with JavaScript

Transform Cards Based on The flipped Class

Card Back Styling

Front Card Styling

Add the Flip with CSS Transitions

Position Cards

Hide the Back Side of Cards

Fix the Unnatural Flip

Perspective

Rotation Direction

Final cleanup

Conclusion

Don't DRY your tests 🌵🏜🦂

The problem

The solution

Let's look at an example

What have we gained?

Reduced cognitive load

Clear signals of intent

Simplified test code maintenance

Immutable Deep State Updates in React with Ramda.js

Hi, I'm Andy Van Slaars

Transform Cards Based on The `flipped` Class