Forem: Tyler Haas

Using CSS Grid in IE11

Tyler Haas — Fri, 29 May 2020 14:56:40 +0000

CSS Grid

Most web apps use a grid system to control their layouts. A grid system is a way
of splitting a web page into a set of columns, usually 12 and using that as the
base of your page layout. This pattern is so common that it became standardized
as
CSS Grid Layout.

Browser Compatibility and Autoprefixer

NOTE: In order to simplify this discussion I'll use the css-in-js library
emotion as our working example of what supporting CSS Grid
looks like.

Many modern CSS features are initially supported through vendor prefixes to
account for differences in browser implementations during early adoption of a
feature. Emotion automatically adds vendor prefixes through the use of stylis's
autoprefixer plugin. This allows us to use things like flexbox without thinking
about browser differences. Unfortunately after a year of research the
maintainers of stylis determined that CSS Grid was not a feature they would be
supporting with their autoprefixer plugin. Here's the TL;DR on the
issue.

Maintainers here don't plan on working on this as it's just not that simple of
a task and any attempts to autoprefix grid for IE11 have their edge cases.
It's also a matter of "least surprise principle" - if we can't make it work
for all cases, we don't want to make it at all because one could think they
can use every grid-related feature safely when that would just not be true.

Andarist

problems with autoprefixing CSS Grid

Lets look at the following table to analyze the differences between the current
implementation of CSS Grid and IE11's implementation.

CSS Grid Properties	IE11 Implementation
grid-template-columns	-ms-grid-columns
grid-template-rows	-ms-grid-rows
grid-template-areas	N/A
grid-template	N/A
grid-auto-columns	N/A
grid-auto-rows	N/A
grid-auto-flow	N/A
grid	N/A
grid-row-start	-ms-grid-row
grid-column-start	-ms-grid-column
grid-row-end	N/A
grid-column-end	N/A
grid-column	N/A
grid-area	N/A
grid-row-gap	N/A
grid-column-gap	N/A
grid-gap	N/A
N/A	-ms-grid-column-span
N/A	-ms-grid-row-span
align-self	-ms-grid-row-align
justify-self	-ms-grid-column-align

As you can see there aren't a lot of cross over between how properties map to
each other. Another big problem is that one of the major benefits to CSS grid is
that you can define spaces between columns with grid-gap. In IE they don't
have any support for this ability. 👎

Manual Prefixing

Given the difficulties with automating the vendor prefixes if you need to
support IE11 then you will need to manually add vendor prefixes. These are the
strategies I employ when doing so in order to simplify things and make my life
easier.

Make heavy use of grid templates

I've seen two styles of writing css grid. The first would look something like
this:

.container {
  display: grid;
  grid-template-columns: 1fr 10px repeat(3, 1fr);
  grid-template-rows: 100px 10px 100px;
  grid-template-areas:
    'a'
    'b b b'
    'c c';
}

.a {
  grid-area: a;
}

.b {
  grid-area: b;
}

.c {
  grid-area: c;
}

The second looks like this:

.container {
  display: grid;
  grid-template-columns: 1fr 10px repeat(3, 1fr);
  grid-template-rows: 100px 10px 100px;
}

.a {
  grid-column: 1;
  grid-row: 1;
}

.b {
  grid-column: 1/3;
  grid-row: 2;
}

.c {
  grid-column: 1/2;
  rid-row: 3;
}

Although the first is really nice for readability and has the nice benefit of
controlling all layout in the parent container I wouldn't use it if you are
worried about IE. IE doesn't support this named syntax you have to declare the
layout via -ms-grid-row/column-span and -ms-grid-row/column and using the
numbering syntax across the board keeps things as similar as possible across
browsers.

Using the second syntax we could write cross browser compatible css that would
look like this:

.container {
  display: grid;
  display: -ms-grid;
  grid-template-columns: 1fr 10px repeat(3, 1fr);
  grid-template-rows: 100px 10px 100px;
}

.a {
  -ms-grid-column: 1;
  -ms-grid-row: 1;
  grid-column: 1;
  grid-row: 1;
}

.b {
  -ms-grid-column: 1;
  -ms-grid-column-span: 3;
  -ms-grid-row: 2;
  grid-column: 1/3;
  grid-row: 2;
}

.c {
  -ms-grid-column: 1;
  -ms-grid-column-span: 2;
  -ms-grid-row: 3;
  grid-column: 1/2;
  rid-row: 3;
}

Don't use gaps

IE's implementation of CSS Grid doesn't support gaps between columns. You could
try to simulate gaps with margin and positioning but I wouldn't recommend it.
Instead I've found it much simpler to use gaps for modern browsers and use CSS
Grids -ms- specific alignment properties to position the elements where you
would like. Here's an example of that.

.container {
  display: grid;
  display: -ms-grid;
  grid-template-columns: 1fr 10px repeat(3, 1fr);
  grid-template-rows: 100px 10px 100px;
}

.a {
  -ms-grid-column: 1;
  -ms-grid-row: 1;
  grid-column: 1;
  grid-row: 1;
}

.b {
  -ms-grid-column: 1;
  -ms-grid-column-span: 3;
  -ms-grid-row: 2;
  -ms-grid-column-align: center;
  grid-column: 1/3;
  grid-row: 2;
}

.c {
  -ms-grid-column: 1;
  -ms-grid-column-span: 2;
  -ms-grid-row: 3;
  -ms-grid-column-align: center;
  -ms-grid-row-align: center;
  grid-column: 1/2;
  rid-row: 3;
}

The Good News

By now I'm sure its obvious there are some definite downsides of using Grid in
IE. Theres no sugar coating it...it sucks. They did do at least one thing right
though. All utility methods are available! Thats right repeat, minmax and
all your other favorite helper functions can be used in IE!

Summary

Supporting CSS Grid for Internet Explorer isn't the most developer friendly
experience but by following the few recommendations I've made in this article
you will make things much easier. If you have other tips you can share I'd love
to hear them! Good luck!

Limiting States

Tyler Haas — Fri, 29 May 2020 00:00:00 +0000

This is a cross post from my blog

Limiting State

State management is hard. This major reason for this is the effects of
combinitorial explosion.
In this article I want explore how we can limit the effects of combinitorial
explosion thus making state easier to manage and our apps simpler.

Modeling State

Most developers spend little time thinking about the possible ways to model
their state. Whatever gets the job done is fine. Right? Lets look at some ways
we could model our state. Lets say we have a toggle component. One
implementation might look like this:

function Toggle() {
  const [on, setOn] = React.useState<boolean>(false)
  return (
    <label aria-label="Toggle">
      <input type="checkbox" checked={on} onClick={() => setOn(on => !on)} />
    </label>
  )
}

This is a pretty simple component that a boolean as state probably works fine
for. But lets suppose our product manager comes to us and says "We only want the
user to be able to toggle when they are logged in". Now our component would look
something like:

interface ToggleProps {
  isLoggedIn: boolean
}

function Toggle({isLoggedIn}) {
  const [on, setOn] = React.useState<boolean>(false)

  function toggleIfLoggedIn() {
    if (isLoggedIn) {
      setOn(on => !on)
    }
  }

  return (
    <label aria-label="Toggle">
      <input type="checkbox" checked={on} onClick={toggleIfLoggedIn} />
    </label>
  )
}

Now we have two pieces of state (props are just passed in state). So the total
possible states we can be in is now 4.

count	isLoggedIn	on
1	false	false
2	false	true
3	true	false
4	true	true

Now lets say that our product manager comes back to us and says: "You know what
lets save whether our toggle is on or off to the database". So we make that
change.

interface ToggleProps {
  isLoggedIn: boolean
}

function Toggle({isLoggedIn}) {
  const [on, setOn] = React.useState<boolean>(false)
  const [error, setError] = React.useState<string>(null)
  const [isLoading, setLoading] = React.useState<boolean>(false)
  const [hasError, setHasError] = React.useState<boolean>(false)

  React.useEffect(() => {
    setLoading(true)
    fetch('apiResource')
      .then(res => res.json())
      .then(data => {
        setLoading(false)
        setOn(data.on)
      })
      .catch(errorResponse => {
        setLoading(false)
        setHasError(true)
        setError(errorResponse)
      })
  }, [])

  function toggleIfLoggedIn() {
    if (isLoggedIn) {
      setOn(on => !on)
    }
  }

  if (isLoading) return <span>Loading...</span>

  if (hasError) return <span>{error}</span>

  return (
    <label aria-label="Toggle">
      <input type="checkbox" checked={on} onClick={toggleIfLoggedIn} />
    </label>
  )
}

now we're getting the explosion of states we were talking about. Here is the
total set of possible states now:

count	isLoggedIn	on	error	isLoading	hasError
1	false	false	null	false	false
2	false	false	null	false	true
3	false	false	null	true	false
4	false	false	null	true	true
5	false	false	string	false	false
6	false	false	string	true	false
7	false	false	string	true	true
8	false	false	string	false	true
9	false	true	null	false	false
10	false	true	null	false	true
11	false	true	null	true	false
12	false	true	null	true	true
13	false	true	string	false	false
14	false	true	string	true	false
15	false	true	string	true	true
16	false	true	string	false	true
17	true	false	null	false	false
18	true	false	null	false	true
19	true	false	null	true	false
20	true	false	null	true	true
21	true	false	string	false	false
22	true	false	string	true	false
23	true	false	string	true	true
24	true	false	string	false	true
25	true	true	null	false	false
26	true	true	null	false	true
27	true	true	null	true	false
28	true	true	null	true	true
29	true	true	string	false	false
30	true	true	string	true	false
31	true	true	string	true	true
32	true	true	string	false	true

Yep. 32 possible states for 5 pieces of state. And this is for state that only
has two possible values for each state. We've all seen states that have
significantly more possible values for each piece of state and significantly
more pieces of state. Consider if any one of these was a complex object that has
properties that are nullable. Things get out of hand really quick if you're not
careful in front end development.

A Better Way to Model Your State

looking at the chart above and thinking about what should be possible can get
us a long way in getting to a better data model. For example if we model our
state in such a way that if the user is not logged in then we can't have any of
these other states that reduces our possible states in half. Further should it
be possible to have both an error and loading at the same time? Probably not.
How about having an error message but hasError be false. Turns out that also
doesn't seem reasonable. What if we changed our model to only allow valid
states? What would that do to our possible states?

Lets look at another data model to explore this idea. Imagine we had the
following.

interface Unauthenticated {
  isAuthenticated: false
}

interface Rejected {
  isAuthenticated: true
  hasError: true
  error: string
}

interface Pending {
  isAuthenticated: true
  isLoading: true
}

interface Success {
  isAuthenticated: true
  on: boolean
}

type ToggleState = Unauthenticated | Success | Rejected | Pending

Which would result in the following possible states:

count	isLoggedIn	on	error	isLoading	hasError
1	false	N/A	N/A	N/A	N/A
2	true	true	N/A	N/A	N/A
3	true	false	N/A	N/A	N/A
4	true	N/A	string	N/A	true
5	true	N/A	N/A	true	N/A

and thats it! 32 possible states becomes just 5 possible states! Thats less than
1/6th of the possibilities. This is much simpler to comprehend and implement and
because we've modeled it in typescript the compiler will catch any places where
we are doing something that our business logic says shouldn't be possible. This
will result in much simpler and maintainable applications.

Conclusion

By modeling our state correctly we are able to limit the amount of possibilities
we have to hold in our heads and consider and we get better TypeScript support.
This helps us to eliminate bugs while simplifying the business logic so its both
easier to understand and contains less surface area for bugs to creep into our
programs.

Referential Equality in React

Tyler Haas — Sat, 16 May 2020 16:14:58 +0000

This is a cross post from my blog

The problem

Last week I was helping out a co-worker with a bug they were experiencing. While
building a custom hook they were retrieving some data, manipulating that data
and setting state. Even though their logs were showing the data was updated, the
component wasn't rendering what was being logged. Their code looked something
like this:

const initialData = {
  foo: {
    list1: [],
    list2: [],
  },
  bar: {
    list1: [],
    list2: [],
  },
};

const useCustomData() {
  const [data, setData] = React.useState(initialData);
  React.useEffect(() => {
    fetch('/path/to/api')
      .then(res => res.json())
      .then(data => data.reduce(transformFn, initialData))
      .then(setData);
  }, [])
  return data;
}

Did you spot it? If not thats ok. This particular bug is subtle and easily
missed.

How react determines when it should re-render

In the React docs we read the following:

The setState function is used to update the state. It accepts a new state
value and enqueues a re-render of the component.

What this is saying is, that anytime we call the state updater function
(setData) returned from useState react will ingest that and trigger a
re-render of our component. But this wasn't happening for us. Why not?

Further down in reacts docs on useState there is
this section
about bailing out of state updates.

If you update a State Hook to the same value as the current state, React will
bail out without rendering the children or firing effects. (React uses the
Object.is comparison algorithm.)

So when our updater function gets called, react will check the value we pass to
it for equality against what it is currently holding in state and if they're the
same it will bail out of re-rendering our component.

The Object.is Algorithm

If we look at the docs for
Object.is
on mdn we will find the description of the algorithm that is used for state
update comparisons.

Object.is() determines whether two values are the same value. Two values are
the same if one of the following holds:

both undefined

both null

both true or both false

both strings of the same length with the same characters in the same order

both the same object (means both objects have same reference)

both numbers and

both +0

both -0

both NaN or

both non-zero and both not NaN and both have the same value

The interesting part of this algorithm is how it deals with detrmining if two
objects are equal. This is done by the objects reference stored in memory. To
fully explain this we have to learn about what happens to an objects reference
when we update one.

Object reference

When a new object is created and bound to a variable what is bound is not the
object itself but a reference to the location of that object in memory. For
example:

const obj = {}

obj would store a memory location instead of the object itself. The result of
this is that when we reference the bound variable we are no longer referencing
the value of the object but instead we reference whatever is stored at that
location in memory. This is done for performance optimization reasons that is
outside the scope of this article.

Solving our problem

Lets unwind what we have learned. Assigning objects to variables gives us a
memory location instead of the value of the object. React then uses the
reference to that memory location to determine if two objects are different and
only re-renders when the two objects are stored in different places in memory.
So if we take another look at our code through the lense of what is bound to our
variables. Our bug begins to make more sense. For simplicity we will represent
objects memory location with strings.

const initialData = 'memoryLocation1';

const useCustomData() {
  const [data, setData] = React.useState('memoryLocation1');
  React.useEffect(() => {
    fetch('/path/to/api')
      .then(res => res.json())
      .then(data => data.reduce(transformFn, 'memoryLocation1'))
      .then(setData);
  }, [])
  return data;
}

with this psuedocode we can see that what we are initializing both useState
and our reduce fn accumulator to the object stored at memoryLocation1. Meaning
that when we call setData we are setting it with the same object reference.
Which kicks off the following conversation:

Us: "Hey React can you update our state?"

React: "Sure. What do you want me to update it with?"

Us: "Please update it with the object stored at memoryLocation1"

React: "No problem! Looks like I've already got that set in state nothing to
do here!"

Us: "No wait! React! There is definitely stuff to do because we updated the
properties of the object! 😡"

So how do we solve this problem? Luckily the solution is fairly simple. We just
have to initialize our reducer function with a totally new object so that the
memory location doesn't match what is already stored in state. One way we could
do this would look like this:

function createInitialObject() {
  return {
    foo: {
      list1: [],
      list2: [],
    },
    bar: {
      list1: [],
      list2: [],
    },
  };
}

const useCustomData() {
  const [data, setData] = React.useState(createInitialObject());
  React.useEffect(() => {
    fetch('/path/to/api')
      .then(res => res.json())
      .then(data => data.reduce(transformFn, createInitialObject()))
      .then(setData);
  }, [])
  return data;
}

This will ensure that we are creating a totally new object each time we invoke
our createInitialObject function.

Conclusion

When working with state in react be mindful of how data is stored in memory and
how react determines that something has changed. In most cases objects are the
primary sticking point. So if you want re-renders to be triggered make sure you
are setting state with entirely new objects!