Forem: tmns

useSelectInnerText: Cross-browser solution for selecting inner text

tmns — Sat, 17 Jun 2023 09:30:23 +0000

What's the issue?

Sometimes you have an element containing text that you would like to automatically be selected when a user clicks into it. A typical example of this is an input, the text of which you want selected in full when clicked so the user can easily delete / replace it.

Sounds straightforward enough, right? Just add an onFocus event handler that calls e.target.select()!

function Input() {
  const ref = useRef<HTMLInputElement>();

  return (
    <label htmlFor="quantity">Quantity</label>
    <input
      ref={ref}
      onFocus={(e) => e.target.select()}
      name="quantity"
      type="text"
    />
  )
}

Unfortunately, life isn't all that easy. In Chrome, this works decently. But in Safari, it is very buggy, often not selecting any text at all, or only selecting some of the text. You can observe this behavior below:

But never fear, I've braved the choppy Safari waters before, and my hacky-ness knows no bounds 😁

What can we do?

Perhaps counterintuitively, we will forego onFocus completely and instead opt for a combination of onClick and onBlur.

First, on click, we will not only select the text but also add the target to a ref object that keeps track of whether it's currently focused. This is to allow the user to click again in the same input and remove the "select all" if desired (i.e., if they don't actually want to delete / replace the entire value).

Then, on blur, the target noted above is removed from the ref object so the "select all" works again.

Taking our example from the previous section, this could look something like:

function Input() {
  const focusedRef = useRef<string | null>();

  return (
    <label htmlFor="quantity">Quantity</label>
    <input
      ref={ref}
      onClick={(e) => {
        // If our ref object has been set to this input and
        // we're getting another event, assume the user wants
        // to edit only a piece of the text and early return.
        if (focusedRef.current === e.currentTarget.name) return;
        // Otherwise, select all and set our ref to the input.
        e.currentTarget.select();
        focusedRef.current = e.currentTarget.name;
      }}
      onBlur={() => {
        // Simply reset our ref so it can be select all'd again.
        focusedRef.current = null;
      }}
      name="quantity"
      type="text"
    />
  )
}

And with that, we get a reliable select all behavior, even in Safari:

🥳🥳🥳

What's the catch?

I haven't discovered one yet, but here's the hook 😜

function useSelectInnerText(): [
  React.MouseEventHandler<HTMLInputElement>,
  React.FocusEventHandler<HTMLInputElement>
] {
  const focusedRef = useRef<string | null>(null);

  const handleClick = useCallback<React.MouseEventHandler<HTMLInputElement>>((e) => {
    if (focusedRef.current === e.currentTarget.name) return;

    e.currentTarget.select();
    focusedRef.current = e.currentTarget.name;
  }, []);

  const handleBlur = useCallback<React.FocusEventHandler<HTMLInputElement>>(() => {
    focusedRef.current = null;
  }, []);

  return [handleClick, handleBlur];
}

With that, our previous example becomes:

function Input() {
  const [handleClick, handleBlur] = useSelectInnerText();

  return (
    <label htmlFor="quantity">Quantity</label>
    <input
      ref={ref}
      onClick={handleClick}
      onBlur={handleBlur}
      name="quantity"
      type="text"
    />
  )
}

🪝

Conclusion

Once again, Safari brings out my creativity. I owe you so much ol' friend.

Hope this helps you out too! Feel free to leave any feedback / questions in the comments 👋

P.S. I actually discovered this behavior over a year ago but thought it was probably just something temporary that would be fixed. Checked again today and it was still there, so figured I should share my approach.

Code-splitting in React WITHOUT Suspense: useLazyLoad

tmns — Sat, 16 Jul 2022 19:31:00 +0000

tl;smtc (too long; show me the code)

You can see a (very contrived) demo and check the hook's code via the below StackBlitz embed. Though, I also suggest opening it in a separate window and observing how the code loads dynamically via your browser's network panel.

Note, I've added a hardcoded delay in the hook to exaggerate the loading time. This is because StackBlitz runs the server in a service worker, so the request always happens instantaneously and can't be easily throttled via e.g. the network panel. You should of course remove it when actually using it in your own project.

Okay, what's this all about?

Recently I found myself implementing a new feature with the following characteristics:

The core piece was a multi-step form, with each step containing complex state and a whole lotta functionality (in other words: a hefty chunk of code).
This form was then to be presented to the user via a modal.
The modal would be triggered via a button interaction.
The kicker: it typically wouldn't be used very often (at least by the majority of users).

A whole bunch of code that most users would never use? Sounds like an ideal case for code-splitting. Naturally, the first approach I considered was React's lazy and Suspense APIs. If you're unfamiliar, given the above implementation in mind, this approach could look something like:

// All our imports...
// Here, we use React's `lazy` to defer loading of all this component's code.
const CreateUserModal = lazy(() => import('./CreateUserModal');
// ...

function Dashboard() {
  // State for controlling when our modal should be visible.
  const [isOpen, setIsOpen] = useState(false);

  return (
    <>
      <button onClick={() => setIsOpen(true)}>Create user</button>
      {isOpen && (
        // Wrapping our deferred component in this `Suspense`
        // is what allows it to not be rendered until its code
        // has been fetched. The `fallback` prop is what gets
        // rendered in its place in the meantime.
        <Suspense fallback={<p>Loading...</p>}>
          <CreateUserModal />
        </Suspense>
      )}
    </>
  )
}

Not too bad right? And for a lot of cases it suffices. But in this particular example there's now quite a thorny UX issue that's been created: where and how should that fallback be rendered when the button is pressed and we wait for the code to be fetched? In the example above, it's simply going to render <p>Loading...</p> next to the button.

We could pass something like a classic skeleton loader to the fallback, and then wrap the Suspense and modal content with some type of modal frame, so that the frame renders on click but the content contains the skeleton until the code is ready.

This is okay, but then you have the problem of trying to match the skeleton style with the content, including its height. And if the height is not something you control, varying at any time, that's even more complexity.

On top of that, what if you also need to perform some data fetching when the modal mounts (yes, that's not the best pattern, but unfortunately real-world projects don't always present us with the most ideal conditions)? Will you then show a skeleton for the code fetching, and then another skeleton for the data fetching? Well, just like we had callback hell, we now often have skeleton hell and I generally try my best not to contribute 💀💀💀

Taking it back to our inline loading state at the beginning, a more subtle approach from the user's perspective would be to stuff that entire Suspense and its fallback within the button itself, rendering something like a spinner when the button is pressed:

<button onClick={() => setIsOpen(true)}>
  {isOpen && (
    <Suspense fallback={<Spinner />}>
      <CreateUserModal close={() => setIsOpen(false)} />
    </Suspense>
  )}{' '}
  Create User
</Button>

Sure, this doesn't seem so bad in this highly contrived and simplified example but it assumes a lot about the structure of our components and code. To take the simplest objection: what if we simply don't want our modal code co-located like that? Too bad! Suspense has to go where you want your loading indicator to go.

You're also a bit limited to how you want your loading state configured. You essentially hand off all your control to Suspense and let it take care of everything. In many cases this may actually be exactly what you want, but sometimes you want more fine-grained control of how exactly the loading is carried out.

So, what is to be done?

Wouldn't it be nice if we could just load our component dynamically and not deal with Suspense at all? While it loads, we could keep track of its loading state and trigger our loading indicator appropriately:

// All our imports...
// Here, set up our module path resolver. It's essentially
// the same thing as before, except without React's `lazy`.
const loadUserModal = () => await('./CreateUserModal');
// Declare the variable we'll eventually load our component into.
let CreateUserModal;

function Dashboard() {
  // State for controlling when our modal should be visible.
  const [isOpen, setIsOpen] = useState(false);
  // State for keeping track of our component loading.
  const [isLoading, setIsLoading] = useState(false);

  async function openUserModal() {
    // If we've already loaded our component, just open & return.
    if (CreateUserModal) {
      setIsOpen(true);
      return;
    }

    // Else, we set our loading state and wait for the module to load.
    setIsLoading(true);
    const module = await loadUserModal();
    CreateUserModal = module.default; // assuming it's a default export.

    // And finally we open the modal and turn our loading off!
    setIsOpen(true);
    setIsLoading(false);
  }

  return (
    <>
      <button onClick={openUserModal}>
        // Here we simply show the spinner when we're 
        // loading. No more `Suspense` boundary!
        {isLoading && <Spinner />} Create User
      </button>
      // Maybe a bunch of other code. We can put it anywhere now!
      {isOpen && <CreateUserModal />}
    </>
  )
}

And just like that, we have full control of how we dynamically load our components! Though note, for dynamic imports to work you may need this preset if using Babel.

Of course, the way we've done it above is a bit limiting. We're just loading a single, specific component. We're assuming it's a default export. We don't even catch any errors. Also, what if we actually don't want to dynamically import a component but just a normal JS module? You know where I'm going with this...

🪝🪝🪝

Let's turn this into a reusable hook!

// Our hook takes an array of module path resolvers
function useLazyLoad(resolvers) {
  const [isLoading, setIsLoading] = useState(false);
  const result = useRef();

  // Always return array with same length as the number of components so the
  // hook's consumer can immediately destructure, for example:
  // const [loading, load, [Comp1, Comp2]] = useLazyLoad([lazyComp1, lazyComp2]);
  const placeholderResult = useRef(Array(resolvers.length));

  // This is the function we return for the consumer to
  // call and initiate loading of the component.
  // It's wrapped in a `useCallback` in case they also
  // want to pass it to a memoized component or otherwise
  // include it as a dependency.
  const load = useCallback(async () => {
    // Do nothing if the modules have already been loaded.
    if (result.current) return;

    try {
      setIsLoading(true);

      // Resolve each module.
      const modulePromises = resolvers.map((resolver) => resolver());
      const modules = await Promise.all(modulePromises);

      // If the module has a default export, return it directly,
      // Otherwise, return the entire object and let consumer handle it.
      result.current = modules.map((module) =>
        'default' in module ? module.default : module
      );
    } catch (error) {
      // Do something with the error...
    } finally {
      setIsLoading(false);
    }
  }, []);

  return [isLoading, load, result.current || placeholderResult.current];
}

Then, going back to our previous example, we can now use our hook like so:

// All our imports...
import useLazyLoad from './useLazyLoad';
const lazyUserModal = () => await('./CreateUserModal');

function Dashboard() {
  const [isOpen, setIsOpen] = useState(false);
  // We call our hook here, passing it the resolver we defined
  // above wrapped in an array. Notice we immediately
  // destructure the result but that's completely optional!
  const [isLoading, load, [CreateUserModal]] = useLazyLoad([lazyUserModal]);

  async function openUserModal() {
    // Here we call the `load` function returned from our hook.
    await load();
    // And open the modal!
    setIsOpen(true);
  }

  // Nothing else changes!
  return (
    <>
      <button onClick={openUserModal}>
        {isLoading && <Spinner />} Create User
      </button>
      // ...
      {isOpen && <CreateUserModal />}
    </>
  )
}

Now all the logic is tucked away neatly in our little lazy hook and we just call it whenever we need to! Much better 🤙

Conclusion

While React's lazy and Suspense APIs definitely have their place and generally make async loading of components (and now, with a compatible library, data!) a piece of cake, sometimes you want handle things on your own.

Suspense boundaries can get messy and difficult to manage. Your code may be structured in a way that doesn't allow for just sticking Suspense wherever you want. Maybe you want more fine-grained control of how the loading itself is carried out. In general, things tend to not play out as cleanly as they do in tutorials (actually, they pretty much never do!). So in those cases, you can try out this approach and let me know how it works for you!

Note on React 18 and `useTransition`

If you're on React 18, you can achieve something quite similar to this by using React's lazy and new hook useTransition:

// All our other imports...
const CreateUserModal = lazy(() => import('../components/CreateUserModal'));

// We'll flip this after our component loads to skip
// subsequent, unnecessary calls to `startTranstion`.
let isLoaded = false;

function Dashboard() {
  const [isOpen, setIsOpen] = useState(false);
  // Call the transition hook. `isPending` tells us the
  // state the transition is in (just like our `isLoading`),
  // and `startTransition` initiates the transition (like our `load`).
  const [isPending, startTransition] = useTransition();

  function openCreateUserModal() {
    // If we've already loaded the code, simply open the modal.
    if (isLoaded) {
      setIsOpen(true);
      return;
    }
    // Else, tell React that we consider setting opening the modal
    // a transition, which you can think of as deprioritizing
    // and as such won't occur until after the component has loaded.
    startTransition(() => setIsOpen(true));
    isLoaded = true;
  }

  // This time, just a change in variable name!
  return (
    <>
      <button onClick={openUserModal}>
        {isPending && <Spinner />} Create User
      </button>
      // ...
      {isOpen && <CreateUserModal />}
    </>
  )
}

You can play around with a demo of that as well at the embed below. Though note that I'm unaware of a way to add a delay to startTransition, so the loading state is near-instantaneous.

And that's all she wrote!

Creating better user experiences with React 18 Suspense and Transitions

tmns — Sat, 01 Jan 2022 17:13:40 +0000

What are you talking about?

React 18 is around the corner and one of the big things coming along with it is Concurrent Mode. The general idea is that it's going to allow for concurrent / interruptible rendering, which in turn will enable us to create more responsive and enjoyable applications for our users.

This post will focus on two Concurrent Mode features in particular, Suspense for Data Fetching and Transitions, which will allow us to create much better loading experiences (and let's face it: we desperately need it!).

Up until now, when needing to fetch data before showing some UI that depends on that data, we typically rendered a loading state in its place, for example a loading spinner or skeleton, until the request resolved with the necessary data.

As an example, let's look at the following CodeSandbox:

Every time we change tabs, the Content component for said tab fetches some data. While that data is being fetched, we render a little loading component in the content's place. This isn't the worst experience and indeed it's more-or-less the standard way we see loading states implemented in apps today.

Wouldn't it be nicer though if we didn't show that in-between loading state at all? What if, instead, we held on to the previous state of the UI until the data was ready? To be fair, we can technically achieve this with React 17 if we really want to but it's definitely a challenge to get right and not very straight-forward. React 18, on the other hand, makes this very simple:

Now instead of switching tabs immediately we stay on the tab we're on and continue to show its content until the new tab's content is ready. We effectively have taken complete control over how we want our loading states to behave. The result is a more seamless and less jarring experience for the user.

This is now a good time to point out that the demo above is a rewrite of the awesome SolidJS demo showcasing its implementation of Suspense and Transitions, which its had for a while now. In general SolidJS and its community is incredible and I highly recommend folks check it out.

If you're a "just show me the code" type of person then that's it! Fork the demo and make it yours! If you want a bit more of an explanation though, continue on!

How does it work?

The magic in this demo, as hinted at in the introduction, lies in the use of Suspense for data fetching and the new useTransition hook.

Setup

First though, in order to enable any of these features, we need to make a small change to how we render our root. Instead of rendering via ReactDOM.render, we use the new ReactDOM.createRoot:

import ReactDOM from "react-dom";
import App from "./App";

const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(<App />);

And just like that we have access to Concurrent Mode!

Suspense (for data fetching)

Now that we're up and running with the new features, we can examine in more details our use of Suspense:

<Suspense fallback={<Loader />}>
  {tab === 0 && <Content page="Uno" resource={resource} />}
  {tab === 1 && <Content page="Dos" resource={resource} />}
  {tab === 2 && <Content page="Tres" resource={resource} />}
</Suspense>

Up until now, we've typically used Suspense when lazy loading components. However in this case our components aren't lazy loaded at all! Instead of suspending on the async loading of the component itself, we're now suspending on the async loading of data within it.

Checking within Content, we see a peculiarly simple component:

function Content({ page, resource }) {
  const time = resource.delay.read();

  return (
    <div className="tab-content">
      This content is for page "{page}" after {time.toFixed()}
      ms.
      <p>{CONTENT[page]}</p>
    </div>
  );
}

Normally we would expect to see a check for time, which would probably be set in state, for example maybe something like:

const [time, setTime] = useState();

useEffect(() => {
  resource.then((data) => {
    setTime(data)
  })
}, [])

return time &&
  (<div className="tab-content">
      This content is for page "{page}" after {time.toFixed()}
      ms.
      <p>{CONTENT[page]}</p>
    </div>
  );

However, instead we see the jsx being unconditionally returned. Further time isn't set in state to trigger a rerender, rather its set to resource.delay.read(). And that's the clue to how this is all working!

You'll see when looking into our fakeAPI file, that resource.delay is actually a special kind of promise, which in our naive implementation taken from the official React examples, is essentially a simplified mock of what something a React 18 compatible data fetching library would provide (and what Relay already does provide!).

The API itself is an implementation detail, the main take-away is that in React 18, Suspense wrapped components will be able to continuously check if the async data a component is attempting to read has been resolved, throwing and continuing to render the fallback until it's ready.

Transitions

With this new use of Suspense, implementing components that depend on async data is much more straight-forward. By itself though, we still can't easily control our loading states. We need the other major piece of our puzzle: the new and shiny useTransition hook.

Note that this hook is really all about defining some state changes as transitional rather than urgent, meaning that if some new work needs to be done during rendering of those changes, React should interrupt the rendering and perform that new work first. For a great in depth example of how this can be used to improve UX, check out this guide from core React team member Ricky Hanlon.

In our case, we're going to use useTransition to tell React that setting the new tab and setting the new resource (which in turn fetches the tab's data) are both transitional state changes and as such we want it to hold off on rendering the resulting UI.

This is accomplished by wrapping both of our transitional state changes in a call to startTransition, which we get from useTransition:

const [isPending, startTransition] = useTransition();

function handleClick(index) {
  startTransition(() => {
    setTab(index);
    setResource(fetchData());
  });
}

You will also notice that along with startTransition we get another utility: isPending. As you can probably guess, this returns true while our transitional changes are still ongoing. This can be used to show an extra piece of loading state so the user knows something is happening in the background.

In our example, that's the "loading bar" at the top, along with some styling changes to the tabs and the content:

<GlobalLoader isLoading={isPending} />
// ...
<div className={`tab ${isPending ? "pending" : null}`}>
// ...

And that's really it! Once you get past the theory and jargon, the practical implementation is very straight-forward. It basically comes down to just wrapping transitional changes with startTransition and handling other UX details with isPending 🙌

That's all folks

If you can't tell, I'm super excited for React 18 and Concurrent Mode. Along with streaming server rendering, this release is going to be a complete game changer as far as React goes. I can't wait to use it in "the real world" to make applications more snappy and users more happy!

Hope you got something out of this as always questions / comments are more than welcome! 🤙

YouTube iframe, shadows, rounded corners, and Safari

tmns — Sat, 23 Oct 2021 12:42:44 +0000

Context

Recently I was tasked with embedding a YouTube video in one of our landing pages. Straight-forward enough it seemed and indeed it was, until a new requirement came in last minute (as they tend to do): the embedded player needed to also have rounded corners.

This requirement complicated things a bit because the embed also had a shadow applied to it. Ultimately, implementing it would lead me to noticing strange behavior regarding shadows in Safari.

Read on if you dare! Alternatively, if you want to just see the code, check out this codepen for an example.

Approach #1: `border-radius`

First, let's take a look at our baseline markup and styles to get a feel for what we were working with:



<div class="container">
  <div class="iframe-wrapper">
    <iframe src="https://www.youtube.com/embed/FcANFVcJeOM?disablekb=1" title="Live performance of Weird Fishes by Radiohead" frameborder="0"></iframe>
  </div>
</div>



.iframe-wrapper {
  position: relative;
  aspect-ratio: 16 / 9;
  box-shadow: 0 0 6px rgb(0 0 0 / 50%);

  iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
  }
}

Note: the styles above are in scss.

My initial thought was to just throw a border-radius on .iframe-wrapper and call it a day. Indeed this seemed to work fine in Chrome and Safari. However, in Firefox the corners looked very choppy and ugly. As such, that option was out.

So, unfortunately, our simple approach #1 == ❌

Approach #2: `clip-path` and `filter: drop-shadow()`

My next thought was to apply a clip-path to the iframe in order to generate the desired border radius and then apply a drop-shadow filter on .iframe-wrapper (so that the generated shadow would respect the shape created by the clip-path):



.iframe-wrapper {
  position: relative;
  aspect-ratio: 16 / 9;
  filter: drop-shadow(0 0 4px rgb(0 0 0 / 50%));

  iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    clip-path: inset(0% 0% 0% 0% round 10px);
  }
}

This looked great in Chrome and Firefox! The jagged corners that were previously being generated by border-radius were gone and in their place was nothing but wonderful smoothness.

I opened up Safari and expected to see the same... but to my horror... what I saw on the screen was a shadow being applied to the player that looked as if I had set a box-shadow on .iframe-wrapper. See the following screenshot for an example (if the quality isn't good enough you can open the codepen in Safari and replace the styles with those above):

What is that??! 🤯

To make things even more strange, on non-touch screen devices this weird extra box shadow would disappear and the correct drop-shadow would appear as soon as Safari lost focus (e.g. switching applications or interacting with something in dev tools). Conversely on mobile it would disappear once I interacted with the page 😱

See the following gif for an example of this behavior (again, if the quality isn't good enough you can open the codepen in Safari and replace the styles with those above). Notice, upon switching to the calendar and back the weird square box shadow disappears and the desired drop shadow comes in:

I still don't understand exactly what the issue was here but indeed it seems that in Safari drop-shadow is not applied correctly on first load.

This, of course, was not acceptable.

So, unfortunately, our approach #2 also == ❌

Approach #3: ?

Now, where could I go from there? How could I simulate a filter: drop-shadow(), i.e. a shadow that respects an inner element's contour?

Somewhat unexpectedly, I discovered that keeping the clip-path on the iframe and applying border-radius and box-shadow to .iframe-wrapper would give me the best of both worlds. That is, the corners would remain smooth in Firefox and the shadow would render correctly in Safari:



.iframe-wrapper {
  --border-radius: 10px;
  position: relative;
  aspect-ratio: 16 / 9;
  border-radius: var(--border-radius);
  box-shadow: 0 0 6px rgb(0 0 0 / 50%);

  iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    clip-path: inset(0% 0% 0% 0% round var(--border-radius));
  }

The only issue I noticed with this approach was that sometimes a strange extra border would peek out from behind the player:

Further, it wasn't always on the right side. Sometimes it would show up on the bottom 😵‍

However, this ended up being solved quite easily by adjusting the background-color of .iframe-wrapper! Further, this also had the side effect of providing a quasi-placeholder as the video loads 🤙

In the end, the following declarations gave me the perfect rounded corners and shadow I was after:



.iframe-wrapper {
  --border-radius: 10px;
  position: relative;
  aspect-ratio: 16 / 9;
  /* The next three declarations simulate
     `filter: drop-shadow(0 0 4px rgb(0 0 0 / 50%));` 
  */
  border-radius: var(--border-radius);
  box-shadow: 0 0 6px rgb(0 0 0 / 50%);
  background-color: rgba(0, 0, 0, 0.3);

  iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    clip-path: inset(0% 0% 0% 0% round var(--border-radius));
  }

So, eventually Approach #3 == 👍

Conclusion

At the end of the day I was quite happy with the result and it worked for the given task. Of course, I would have liked to stop at Approach #2 (just drop-shadow); however, I couldn't release something that would look bad on Safari and in turn iOS.

What do you think about this Safari issue? Have you ever ran into it yourself? I couldn't find anything about it in my research 🤷‍♂️

Let me know!

Update / Approach #4

Just saw a cool effect being used on the YouTube embed at Next.js Conf. They set a linear gradient background with a blur on a pseudo element of the embed's container / wrapper div.

This could also be used in our case to achieve our desired shadow, replacing the three declarations added in Approach #3:



.iframe-wrapper {
  position: relative;
  aspect-ratio: 16 / 9;

  &::before {    
    content: "";
    position: absolute;
    inset: -5px;
    z-index: -1;
    background: #000;
    filter: blur(10px);
    opacity: .75;
  }

  iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    clip-path: inset(0% 0% 0% 0% round 10px);
  }
}

This is a nice approach and seems to work well in all browsers. This conference hasn't even started yet and I've already learned something 😄

useCancelToken: a custom React hook for cancelling Axios requests

tmns — Sat, 10 Apr 2021 09:17:48 +0000

Update

Note that as of Axios v0.22.0, the cancelToken API is deprecated in favor of using a fetch-like AbortController.

There are already various hooks available online for AbortController so I won't recreate it here but at a high-level it's conceptually quite similar to the cancel token!

What's the problem?

When developing with React and updating state inside of components, you may have come across the following error before:

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application.

While this error could pop up for various reasons, one common cause is attempting to update state within the callback of a network request after the component has been destroyed.

For example, imagine we have a modal (yes I know, modals are inherently problematic, but for a lot of us they're also unavoidable) that when opened makes a request for some super important data it needs to set in state and show to the user:

const Modal = () => {
  const [importantData, setImportantData] = useState({});

  useEffect(() => {
    axios.get('/important_data')
      .then((response) => {
        setImportantData(response.data);
      });
  }, []);

  return (
    // JSX with important data
  )
}

Note: While this post is about Axios specifically, the idea can be applied to other APIs, like fetch.

This is nice and works swimmingly when the user opens the modal and keeps it open. But what if they close it while the request is still in process? Sure the component may be gone; however, that callback within .then() is still hanging around waiting to get executed.

Assuming the component unmounts on close, this will cause the error noted above to occupy our console like the US occupying native land, since we'll be attempting to set our importantData state within a component that no longer exists.

What can we do about it?

One solution to this issue is to ensure that whenever our component unmounts, we cancel our pending request.

"But our request is already gone!" I hear you say.. "How can we cancel it??" you yell in despair..

Never fear fellow dev frantically trying to finish a feature before their deadline, as the folks behind Axios have already responsibly built in cancellation functionality!

The idea is that we create a cancel token and send it along with our request, which allows for us to cancel said request whenever we like.

In our Modal component, this would look something like the following:

const Modal = () => {
  const [importantData, setImportantData] = useState({});

  useEffect(() => {
    const source = axios.CancelToken.source(); 
    axios.get('/important_data', {
      cancelToken: source.token
    }).then((response) => {
      setImportantData(response.data);
    }).catch((error) => {
      if (axios.isCancel(error)) return;
    });

    return () => source.cancel();
  }, []);

  return (
    // JSX with important data
  )
}

Notice now we're performing a few extra steps with our lil axios. Before we send the request we now create a source variable holding the result of axios.CancelToken.source, which is like a reference that we can associate with our request.

Then, along with our request we send an extra piece of data, cancelToken, containing our source's token.

However, this alone still doesn't accomplish our goal of cancelling on unmount!

So, we also make sure to return a function from our useEffect that cancels our source's token, which by design will run when the component unmounts.

Also note that when we cancel a token, the pending promise is rejected, resulting in an error. If you don't handle this error, it will pop up in the console.

Conveniently, Axios also provides an isCancel function which allows you to determine if an error returned from a request is due to a cancellation, which you can see above in our catch block.

This is cool for one-off use cases, but realistically we're going to need to reuse this functionality in many components (and even many times in the same component). So let's make our own hook out of it!

Hook, line, something something..

import { useRef, useEffect, useCallback } from 'react';
import { CancelToken, isCancel } from 'axios';

/**
 * When a component unmounts, we need to cancel any potentially
 * ongoing Axios calls that result in a state update on success / fail.
 * This function sets up the appropriate useEffect to handle the canceling.
 *
 * @returns {newCancelToken: function, isCancel: function}
 * newCancelToken - used to generate the cancel token sent in the Axios request.
 * isCancel - used to check if error returned in response is a cancel token error.
 */
export const useCancelToken = () => {
  const axiosSource = useRef(null);
  const newCancelToken = useCallback(() => {
    axiosSource.current = CancelToken.source();
    return axiosSource.current.token;
  }, []);

  useEffect(
    () => () => {
      if (axiosSource.current) axiosSource.current.cancel();
    },
    []
  );

  return { newCancelToken, isCancel };
};

The hook, useCancelToken, utilizes useRef to store our cancel token source. This is so that our source remains the same in case of a more complex component where re-renders may occur while a request is being made.

Further, our hook sets up and exports a newCancelToken function, which sets the ref's current value to the created source and returns the token itself, so the consumer can send it along with their request. Note, that this function is memoized via useCallback, so that it can safely be added to a useEffect dependency array without causing an infinite loop of rendering.

I like this approach as I don't think the person using this hook should have to deal with the source object at all. All they should have to do is send the token with the request and let the hook handle the rest!

Last but not least, we set up a useEffect with the sole purpose of cancelling the current source's token on unmount.

Note, we also export isCancel so the consumer can handle their request failure errors appropriately.

So, how would we use this in our Modal component?

import { useCancelToken } from './hooks.js';

const Modal = () => {
  const [importantData, setImportantData] = useState({});
  const { newCancelToken, isCancel } = useCancelToken();

  useEffect(() => {
    axios.get('/important_data', {
      cancelToken: newCancelToken()
    }).then((response) => {
      setImportantData(response.data);
    }).catch((error) => {
      if (isCancel(error)) return;
    });
  }, [newCancelToken, isCancel]);

  return (
    // JSX with important data
  )
}

Now all we do is call our newCancelToken() function when sending our request and check the potentially resulting error with isCancel. We don't even have to set up a cleanup return function!

happy dance

*Note that calling newCancelToken multiple times within the same component won't actually allow you to cancel multiple requests. For that you either need to call it once and pass the cancelToken to each request (also storing it in a ref if the component might re-render) or tweak the hook to return the cancelToken instead of the function, as Mostafa helpfully explains in their comment.

Conclusion

When developing it can be easy to forget about all the uncertainties and gotchas of real-world use.

Maybe the end user's network isn't as fast as the one we're developing on. Maybe they lose connectivity midway through using a feature. Maybe they didn't want to use said feature at all and navigate away from it / close it immediately. And so on and so on.

Thus, it's important to program a bit defensively and ensure we cover our bases. Using a cancel token for async routines is one such example.

Also - I wrote tooken instead of token way too many times while writing this. Also also - tooken > taken.

11ty Feedback: A starter project for exchanging meaningful feedback

tmns — Sun, 04 Apr 2021 18:52:53 +0000

Show me the demo!
Show me the code!

What's all this ruckus?

Corporate style feedback processes can often be cold, invasive, and ultimately unfulfilling.

Typically feedback gets collected in the form of a performance review, which your manager, along with your manager's manger, and you manager's manager's manager (you get the point) have access to, even though it may be something you consider quite personal.

Further, the possibility that those in positions of power may read this feedback can influence both what the feedback-giver writes and how the feedback-receiver copes with the process as a whole. Reviews can cause anxiety, stress, and fear.

In a sentence: traditional reviews can be awful.

Giving and receiving feedback should be a sincere moment of mutual exchange, support, and learning! Both sides should feel as comfortable and safe as possible while fulfilling their parts.

So...

I put together a lightweight 11ty starter project that gets you up and running with a way of carrying out your own (better) feedback process!

All you need to do is set your goals, deploy to Netlify, and send the link to those you would like feedback from.

You can check out a live demo here.

This project in turn hopes to provide a quick-and-easy means of attracting and receiving sincere, helpful feedback.

While ideally such a process would take place in person, for a lot of us that isn't an option these days. Using this site over a video call however could be a decent alternative.

How?

The feedback process implemented is inspired by an amazing post by Chelsea Troy titled Attracting Feedback, in which she goes into great detail explaining the benefits of using a goal-based feedback process.

If you haven't read this post yet, I highly encourage you to do so before the next time you plan on asking for feedback. Also note, if you're preparing to give feedback, Chelsea has written other in-depth posts that look at all sides of the feedback process.

Finally, if you're more interested in the technical bits, you can see some relevant info at the template's repo.

Build a Responsive Nav BBC & Smashing Magazine Style!!

tmns — Tue, 15 Sep 2020 19:10:10 +0000

Context

While re-designing a friend's site from scratch recently I decided I wanted to do something different than the ol' hamburger for a responsive nav. I really like how Smashing Magazine has designed theirs - with nav items gradually disappearing from the main nav and appearing within the secondary nav as the viewport width decreases.

For a while I just assumed they were using JavaScript; however, after turning JS off while browsing their site I was surprised to see it still working! It turns out they use grid and a series of media queries to get their desired effect. I've recreated the basic functionality in this codepen - feel free to use it as a reference for building your own!

BBC goes the JS route but with progressive enhancement so things don't break completely under JS-less conditions. Thankfully, some wonderful folks there have published guidelines and mini-tutorials for many of their components (with accessibility in mind!!). If I'm not mistaken, the supernaturally awesome Heydon Pickering participated in this, so you know it's quality!

The BBC folks call this component the Masthead and it is a requirement that it still serves its purpose (ie, to provide users with a set of navigation links) under the following circumstances:

No JavaScript: The functionality must be available to users whose browsers are not running JavaScript

JavaScript but no IntersectionObserver: The IntersectionObserver API is the most efficient way to allot a suitable number of promoted navigation links within the available space. These links must still be available where the browser does not support IntersectionObserver.

With those rules in mind, let's get started building our own version! At any time throughout the process you can refer to this codepen to ensure you're on the right track!

Adding some HTML & CSS

Since we want to progressively enhance our nav, we will start out by building the most simple version that will always display all nav items, in order to ensure that all users will be able to access all of our information!

Let's begin with the HTML:

<header>
  <nav aria-label="Our Site">
    <a href="">
      <svg class="w-6 h-6" fill="none" stroke="currentColor" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg">
        <path d="M12 14l9-5-9-5-9 5 9 5z"></path>
        <path d="M12 14l6.16-3.422a12.083 12.083 0 01.665 6.479A11.952 11.952 0 0012 20.055a11.952 11.952 0 00-6.824-2.998 12.078 12.078 0 01.665-6.479L12 14z"></path>
        <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M12 14l9-5-9-5-9 5 9 5zm0 0l6.16-3.422a12.083 12.083 0 01.665 6.479A11.952 11.952 0 0012 20.055a11.952 11.952 0 00-6.824-2.998 12.078 12.078 0 01.665-6.479L12 14zm-4 6v-7.5l4-2.222"></path>
      </svg>
    </a>
    <div class="main-nav">
      <ul>
        <li data-index="0">
          <a href="">Link 1</a>
        </li>
        <li data-index="1">
          <a href="">Link 2</a>
        </li>
        <li data-index="2">
          <a href="">Link 3</a>
        </li>
        <li data-index="3">
          <a href="">Link 4</a>
        </li>
        <li data-index="4">
          <a href="">Link 5</a>
        </li>
        <li data-index="5">
          <a href="">Link 6</a>
        </li>
        <li data-index="6">
          <a href="">Link 7</a>
        </li>
        <li data-index="7">
          <a href="">Link 8</a>
        </li>
        <li data-index="8">
          <a href="">Link 9</a>
        </li>
        <li data-index="9">
          <a href="">Link 10</a>
        </li>
        <li data-index="10">
          <a href="">Link 11</a>
        </li>
      </ul>
    </div>
  </nav>
</header>

That's it, a header where I'll apply some wrapper-type styles, the first svg I saw from Heroicons, and the nav itself consisting of a ul with eleven items. Note we're also adding a custom data-index attribute to each list item, which we will use later when toggling styles with IntersectionObserver.

Now, you will probably notice that it's not the prettiest nav in the world; in fact, it looks just like a measly ol' list (because that's all a nav typically is!). Let's improve that a bit by adding some CSS (keep in mind, the styles here are written with Codepen's "Reset" base styles also applied):

header {
  position: relative;
  margin-right: auto;
  margin-left: auto;
  background-color: burlywood;
  padding: 1rem 4rem 2rem;
  max-width: 64rem;
  color: darkslategray;
  font-family: Arial, Helvetica, sans-serif;
  font-weight: 900;
}

nav {
  display: flex;
  position: relative;
  align-items: center;
  justify-content: center;
}

svg {
  width: 5rem;
  height: 5rem;
}

nav div {
  margin-left: 3rem;
}

ul {
  display: flex;
  flex-wrap: wrap;
  list-style: none;
  padding: 1rem;
}

li {
  padding-top: 1rem;
  padding-left: 2rem;
}

a {
  display: block;
  position: relative;
  text-decoration: none;
  white-space: nowrap;
  color: inherit;
}

a:focus {
  outline: 2px dashed white;
  outline-offset: 0.25rem;
}

ul a:hover {
  transform: rotate(-3deg);
}

Okay! That's a little nicer now! It should be noted here that all of the styles (eg spacing, color, hover effects) are completely arbitrary. The only real important bit is the setting of flex and flex-wrap: wrap on our ul. This enables the nav items to wrap as the viewport width decreases. And with that, our most basic responsive nav is complete!

Alternatively, if you want to avoid flex you can accomplish the same wrapping behavior by going old school and setting float: left on all our elements. We'll stick with flex here though.

Now let's add some extra functionality in the case that the user has JS enabled. We can add another item to the main nav that will act as a type of secondary nav, where we will "hide" items from the main nav as the viewport width decreases.

Let's place the markup for this extra item before the closing tag for our nav:

[...]
    </div>
    <div class="nav__more-item" style="display: none;">
      <a href="#secondary-nav" role="button" aria-haspopup="true" aria-expanded="false">
        <span class="visually-hidden">More</span>
        <span aria-hidden="true">More</span>
      </a>
    </div>
  </nav>
</header>

Note that the entire div has a style attribute with display: none;. Remember, if the user does not have JS, we don't want to show this piece of functionality; so, we set its default display value to none and we will change it later via JS.

The CSS for this piece will consist of a little hover effect and an accessible way of visually hiding an element, which I learned from Andy Bell:

.nav__more-item {
  padding-top: 1rem;
}

.nav__more-item a:hover {
  background: darkslategray;
  color: burlywood;
}

.visually-hidden {
  position: absolute;
  margin: 0;
  border: 0;
  padding: 0;
  width: 1px;
  height: auto;
  overflow: hidden;
  white-space: nowrap;
  clip: rect(0 0 0 0);
}

Now let's add the HTML for the actual menu itself, which we will place right outside our nav, before the closing header tag:

[...]
  </nav>
  <div id="secondary-nav" class="secondary-nav" style="display: none;">
    <ul class="secondary-nav__list">
      <li data-index="0">
        <a href="">Link 1</a>
      </li>
      <li data-index="1">
        <a href="">Link 2</a>
      </li>
      <li data-index="2">
        <a href="">Link 3</a>
      </li>
      <li data-index="3">
        <a href="">Link 4</a>
      </li>
      <li data-index="4">
        <a href="">Link 5</a>
      </li>
      <li data-index="5">
        <a href="">Link 6</a>
      </li>
      <li data-index="6">
        <a href="">Link 7</a>
      </li>
      <li data-index="7">
        <a href="">Link 8</a>
      </li>
      <li data-index="8">
        <a href="">Link 9</a>
      </li>
      <li data-index="9">
        <a href="">Link 10</a>
      </li>
      <li data-index="10">
        <a href="">Link 11</a>
      </li>
    </ul>
  </div>
</header>

Again, note we are setting its default display to none.

Now let's add some CSS just to make it a little nicer on the eyes:

.secondary-nav__list {
  position: absolute;
  top: 75%;
  right: 0;
  flex-direction: column;
  align-items: center;
  transform: translateX(-7%);
  border-radius: 0.77rem;
  box-shadow: 0 13px 27px -5px rgba(50, 50, 93, 0.25),
    0 8px 16px -8px rgba(0, 0, 0, 0.3), 0 -6px 16px -6px rgba(0, 0, 0, 0.025);
  background-color: darkslategray;
  padding: 1rem 2rem 2rem;
  min-width: 5rem;
  height: auto;
  color: burlywood;
}

.secondary-nav__list::before {
  content: '';
  display: block;
  position: absolute;
  top: 1px;
  left: 50%;
  transform: translate(-50%, -100%);
  border-right: 15px solid transparent;
  border-bottom: 15px solid darkslategray;
  border-left: 15px solid transparent;
  width: 0;
  height: 0;
}

.secondary-nav__list li {
  padding-left: 0;
}

And with that we've actually written all the HTML and CSS necessary for our nav. From here on out we will just be applying bits of CSS via JS. Let's get to it!

Adding some JS

Nearly all of the JS here is directly based on the JS written for the demo masthead linked above. So all credit goes to the folks who had a helping hand in creating it. It's also included unminified and with helpful comments, so check it out if you need more clarification on something.

Let's kick our version off by setting some essential styles. We will:

Set overflow-x of our nav to auto so the user will be able to still scroll and see all the menu items if their browser does not support IntersectionObserver . This style will be set to hidden later if IntersectionObserver is supported.
Set flex-wrap of the nav list to nowrap so the items don't just simply wrap when the viewport width decreases.
Set display block on our "More" nav item.

var mainNav = document.querySelector('.main-nav');
mainNav.style.overflowX = 'auto';
mainNav.firstElementChild.style.flexWrap = 'nowrap';

var moreMenuItem = document.querySelector('.nav__more-item');
moreMenuItem.style.display = 'block';

Great! You should now be seeing the More nav item we added in the previous section. Now let's add an event listener to it that shows / hides the secondary nav menu on click:

var moreMenuLink = moreMenuItem.querySelector('a');
var secondaryNav = document.querySelector('.secondary-nav');

moreMenuLink.addEventListener('click', function (e) {
  e.preventDefault();

  var expanded = moreMenuLink.getAttribute('aria-expanded') === 'true' || false;
  moreMenuLink.setAttribute('aria-expanded', !expanded);

  var open = secondaryNav.style.display === 'flex' || false;
  secondaryNav.style.display = open ? 'none' : 'flex';

  if (!open) {
    var firstVisibleItem = secondaryNav.querySelector('li[style="display: block;"] a');
    firstVisibleItem.focus();
  }
});

Let's also add two keydown event listeners: one on the menu link to make it behave like a button and open the secondary nav on space and one on the secondary nav to close on esc:

moreMenuLink.addEventListener('keydown', function (e) {
  if (e.keyCode === 32) {
    e.preventDefault();
    moreMenuLink.click();
  }
});

secondaryNav.addEventListener('keydown', function (e) {
  if (e.keyCode === 27) {
    e.preventDefault();
    moreMenuLink.setAttribute('aria-expanded', false);
    secondaryNav.style.display = 'none';
    moreMenuLink.focus();
  }
});

Adding some `IntersectionObserver`

Now has come the time for the grand finale - enter stage left the IntersectionObserver!

This article assumes a level of familiarity with the concept and functionality of the API - if you're looking for an in-depth explanation I highly recommend this really great write up by Heather Weaver.

First, let's ensure its supported by the browser and turn off the overflow-x we had previously set on the main nav if it is. Let's also configure the settings for our observer while we're at it. Note, we are setting the root property of the observer to the div that wraps the main nav ul:

if ('IntersectionObserver' in window) {
  mainNav.style.overflowX = 'hidden';

  var observerSettings = {
    root: mainNav,
    threshold: 0.98
  }

Now let's define the function that we'll pass to the observer to be called every time an intersection occurs:

  var secondaryNavItems = secondaryNav.querySelectorAll('li');

  var callback = function (items, observer) {
    Array.prototype.forEach.call(items, function(item) {
      var index = parseInt(item.target.dataset.index);
      if (item.intersectionRatio > 0.98) {
        item.target.style.visibility = 'visible'; 
        secondaryNavItems[index].style.display = 'none';
      } else {
        item.target.style.visibility = 'hidden';
        secondaryNavItems[index].style.display = 'block';
      }
    });    
  };

We determine which item to display in the secondary nav by checking the value of the observed item's data-index attribute, which is its 0-index of its render order. Since both list's items are rendered in the same order, we can use its index to find the correct item in the secondary nav list.

Finally, we initialize our observer with our settings and callback and call observe on each of our main nav items:

  var mainNavItems = mainNav.querySelectorAll('li');

  var observer = new IntersectionObserver(callback, observerSettings);
  Array.prototype.forEach.call(mainNavItems, function(item) {
    observer.observe(item);
  });
}

And voila! Just like that we are finished with our observer as well as our entire responsive, hamburgerless nav bar!!

Side note: I just realized I could have been making vegetarian puns this whole time insert facepalm emoji

Conclusion

I really love figuring out how things like this work, aside from the momentary fits of rage that occur when I set flex on the wrong element. So I hope this little article decreases the number of other folks' fits of rage and helps out anyone that is interested in building something similar.

Feel free to reach out if you have any questions or comments. & have fun!!

Adding Authentication to RedwoodJS (the hard way)

tmns — Sun, 12 Apr 2020 14:47:54 +0000

What?

RedwoodJS is a new (still in alpha) JAMstack-inspired framework that helps you build React-GraphQL
web applications quickly and enjoyably. It is unabashedly opinionated, with the goal of making the structural (read: boring) decisions for you, in turn allowing you to dive straight into the creative (read: fun) parts.

Over the past few weeks I have been building a small project with RedwoodJS and overall have been very pleased with the developer experience, as well as the official docs. However, when I eventually reached the point of adding authentication / authorization to the project, I realized that this hadn't been implemented yet by RedwoodJS the team.

Naturally, they are aware that such an important feature is missing and it is actually currently a main priority of theirs. Considering they're also super capable, it could even be implemented by the time I finish writing this - making the text obsolete - but in the case it isn't - read on :)

How?

It's worth noting up-front that this isn't the simplest solution out there. You could for example use something like Netlify Identity or Magic Link if it suits your use case. However, my use case was a little particular in that I wanted to allow logging in but exclude registration (done manually via a side-channel), which led me to Firebase.

To get started, you will first need to create a new project in Firebase. You will then have to "add an app" to this new project, which you can find the option for in Settings -> General (at the time of writing). This process can be a little confusing if you've never worked with the Firebase console before but there are plenty of guides out there if you get lost navigating all its buttons and tabs.

Once you've added an app to your project, Firebase should present you with some configuration values, looking something like the following:

  // Your web app's Firebase configuration
  var firebaseConfig = {
    apiKey: "example",
    authDomain: "example.firebaseapp.com",
    databaseURL: "example",
    projectId: "example",
    storageBucket: "example.appspot.com",
    messagingSenderId: "example",
    appId: "example"
  };

Assuming you already have a RedwoodJS app set up, you will want to locate and save these values in its .env file (by default ignored by git), like so:

REACT_APP_API_KEY="example"
REACT_APP_AUTH_DOMAIN="example.firebaseapp.com"
REACT_APP_DATABASE_URL="example"
REACT_APP_PROJECT_ID="example"
REACT_APP_STORAGE_BUCKET="example.appspot.com"
REACT_APP_MESSAGING_SENDER_ID="example"
REACT_APP_APP_ID="example"

Now that we have our configuration values, let's begin building out our authentication hook, which will take advantage of React's useContext. Luckily enough, a great example of such a hook (along with its application) already exists for us to use, which you can see in its entirety over at useHooks.

Let's first import all the necessary dependencies, including some of Redwood's router methods, and initialize our Firebase app with the above configuration (this can be done in a new file, e.g. src/context/use-auth.js):

import { useState, useEffect, useContext, createContext } from 'react'
import { navigate, routes } from '@redwoodjs/router'
import * as firebase from 'firebase/app'
import 'firebase/auth'

firebase.initializeApp({
  apiKey: process.env.REACT_APP_API_KEY,
  authDomain: process.env.REACT_APP_AUTH_DOMAIN,
  databaseURL: process.env.REACT_APP_DATABASE_URL,
  projectId: process.env.REACT_APP_PROJECT_ID,
  storageBucket: process.env.REACT_APP_STORAGE_BUCKET,
  messagingSenderId: process.env.REACT_APP_MESSAGING_SENDER_ID,
})

Now, we can continue on in the same file - exporting an authentication context provider and a corresponding useAuth hook:

const authContext = createContext()

export function ProvideAuth({ children }) {
  const auth = useProvideAuth()
  return <authContext.Provider value={auth}>{children}</authContext.Provider>
}

export const useAuth = () => useContext(authContext)

But where does this useProvideAuth come from?? We'll build it now! It will be in this function that we will implement our signin and signout functions (as well as registration, reset-password, and any other authentication logic you want). Also, we will utilize useEffect to watch the user's authentication status and keep it in sync with a user reference we will export along with our authentication functions:

function useProvideAuth() {
  const [user, setUser] = useState(null)
  const [error, setError] = useState(null)

  const signin = (email, password) => {
    return firebase
      .auth()
      .signInWithEmailAndPassword(email, password)
      .then((response) => {
        setUser(response.user)
        navigate(routes.orders())
      })
      .catch((error) => {
        setError(error)
      })
  }

  const signout = () => {
    return firebase
      .auth()
      .signOut()
      .then(() => {
        setUser(false)
        navigate(routes.home())
      })
      .catch((error) => {
        setError(error)
      })
  }

  useEffect(() => {
    const unsubscribe = firebase.auth().onAuthStateChanged((user) => {
      if (user) {
        setUser(user)
      } else {
        setUser(false)
      }

      return () => unsubscribe()
    })
  }, [])

  return {
    user,
    error,
    signin,
    signout,
  }

Note that in my example above, on successful login I call navigate(routes.orders()), which is Redwood's way of programmatically navigating the user to a specific route. Here, I navigate the user to an "/orders" route that exists in my application. Of course, for your own project you would change this to your own desired route, or even remove it completely if it doesn't suit your needs.

Great! So now we have our authentication context provider and hook - but how do we use them? The most direct way I found was first adding the provider to the main web/src/index.js file, like so:

import ReactDOM from 'react-dom'
import { RedwoodProvider, FatalErrorBoundary } from '@redwoodjs/web'
import FatalErrorPage from 'src/pages/FatalErrorPage'

import Routes from './Routes'
import { ProvideAuth } from './context/use-auth'

import './scaffold.css'
import './index.css'

ReactDOM.render(
  <FatalErrorBoundary page={FatalErrorPage}>
    <RedwoodProvider>
      <ProvideAuth>
        <Routes />
      </ProvideAuth>
    </RedwoodProvider>
  </FatalErrorBoundary>,
  document.getElementById('redwood-app')
)

Then, if for example we have a login page, we can use our hook like so:

// all our other imports
import { useAuth } from 'src/context/use-auth'

[...]

const LoginForm = () => {
  const { signin, error } = useAuth()

  const onSubmit = ({ email, password }) => {
    signin(email, password)
  }

  return (
    <FormContainer>
      <FormStyled
        onSubmit={onSubmit}
        validation={{ mode: 'onBlur' }}
      >
        <Heading style={{ color: '#3273dc' }}>Login</Heading>
        <SubmitError>
          {error && 'Incorrect username or password'}
        </SubmitError>
[...]

Above we're using destructuring to assign the returned object's values of useAuth directly to signin and error, but you could also return the whole object to a variable (e.g. auth) and use it that way (e.g. auth.signin and auth.error).

Similarly, if we wanted to render a component based on the authentication status of the user, say a login button if they're logged out and a logout button if they're logged in, we could do something like so:

const Navbar = () => {
  const { user, signout } = useAuth()

  const LoginButton = () => (
    <Link to={routes.login()}>
      <Button color="info" outlined>
        Login
      </Button>
    </Link>
  )

  const LogoutButton = () => (
    <Button color="info" outlined onClick={() => signout()}>
      Logout
    </Button>
  )

  return (
[...]
        <Navbar.Container position="end">
          <Navbar.Item renderAs="div">
            {user ? <LogoutButton /> : <LoginButton />}
          </Navbar.Item>
        </Navbar.Container>
      </Navbar.Menu>
    </NavbarStyled>
  )

Okay, so we now have authentication working and can even render components depending on the authentication status of our user - but what about conditionally rendering routes? How do we protect routes that we don't want unauthenticated users to access?

Attempting to answer this question led me down a dark path of severe trial and error. I will keep it short and sweet here, focusing on the solution I came up with rather than all the failures. If you want to hear me rant though, feel free to reach out! ^_^

Let's first create a separate App component, which will use React Suspense to lazy load versions of our routes, based on the authentication status of our user:

// web/src/app.js
import { lazy, useEffect, Suspense } from 'react'
import { css } from '@emotion/core'
import ClipLoader from 'react-spinners/ClipLoader'

import { useAuth } from 'src/context/use-auth'

const loadAuthRoutes = () => import('./AuthRoutes.js')
const AuthRoutes = lazy(loadAuthRoutes)
const Routes = lazy(() => import('./Routes.js'))

const override = css`
  display: block;
  margin: 3em auto 0 auto;
  font-size: 4em;
  border-color: #3273dc;
`

function App() {
  const { user } = useAuth()

  useEffect(() => {
    loadAuthRoutes()
  }, [])

  return (
    <Suspense fallback={<ClipLoader css={override} />}>
      {user ? <AuthRoutes /> : <Routes />}
    </Suspense>
  )
}

export default App

// and slightly modify web/src/index.js to use App instead of Routes
import App from './app'
import { ProvideAuth } from './context/use-auth'

import './scaffold.css'
import './index.css'

ReactDOM.render(
  <FatalErrorBoundary page={FatalErrorPage}>
    <RedwoodProvider>
      <ProvideAuth>
        <App />
      </ProvideAuth>
    </RedwoodProvider>
  </FatalErrorBoundary>,
  document.getElementById('redwood-app')
)

This is quite similar to what's suggested by Kent C. Dodds in this post of his on authentication. The main difference here is that were solely importing different routes. Actually, the routes themselves technically are the same, we just have to add an extra attribute to our protected routes:

// web/src/Routes.js
import { Router, Route } from '@redwoodjs/router'

const Routes = () => {
  return (
    <Router>
      <Route path="/login" page={LoginPage} name="login" />
      <Route 
        path="/orders" 
        page={OrdersPage} 
        name="orders" 
        redirect="/login" />
      <Route
        path="/orders/{id:Int}"
        page={OrderPage}
        name="order"
        redirect="/login"
      />
      <Route
        path="/orders/{id:Int}/edit"
        page={EditOrderPage}
        name="editOrder"
        redirect="/login"
      />
      <Route
        path="/orders/new"
        page={NewOrderPage}
        name="newOrder"
        redirect="/login"
      />
      <Route path="/" page={HomePage} name="home" />
      <Route notfound page={NotFoundPage} />
    </Router>
  )
}

export default Routes

// web/src/AuthRoutes.js
import { Router, Route } from '@redwoodjs/router'
import LoginPage from 'src/pages/LoginPage'
import HomePage from 'src/pages/HomePage'
import NotFoundPage from 'src/pages/NotFoundPage'
import OrdersPage from 'src/pages/OrdersPage'
import OrderPage from 'src/pages/OrderPage'
import EditOrderPage from 'src/pages/EditOrderPage'
import NewOrderPage from 'src/pages/NewOrderPage'

const AuthRoutes = () => {
  return (
    <Router>
      <Route path="/login" page={LoginPage} name="login" redirect="/orders" />
      <Route path="/orders" page={OrdersPage} name="orders" />
      <Route path="/orders/{id:Int}" page={OrderPage} name="order" />
      <Route path="/orders/{id:Int}/edit" page={EditOrderPage} name="editOrder" />
      <Route path="/orders/new" page={NewOrderPage} name="newOrder" />
      <Route path="/" page={HomePage} name="home" />
      <Route notfound page={NotFoundPage} />
    </Router>
  )
}

export default AuthRoutes

So, what we essentially do is add a redirect option to each of the routes we want protected in Routes.js, which is the default set of routes loaded when a user is authenticated. This ensures the user is redirected to the login screen (in my example) whenever they attempt to access such a route.

Then, we create another routes file (AuthRoutes.js), which imports and defines all of the same routes, but without the redirect attribute on our protected routes, letting the user access them normally upon authentication.

Note, at the time of writing the redirect attribute isn't noted in the Redwood docs, I found out about it by looking at the source of the router itself:

  const routes = React.Children.toArray(children)
[...]
  for (let route of routes) {
    const { path, page: Page, redirect, notfound } = route.props
[...]
      if (redirect) {
        const newPath = replaceParams(redirect, pathParams)
        navigate(newPath)
        return (
          <RouterImpl pathname={newPath} search={search}>
            {children}
          </RouterImpl>
        )
      }
[...]

Also, you may notice something interesting when looking at the source and how it handles the children of the Router component. It takes in all children, regardless of the component name, and then performs a set of operations on them. This means for example you could write something like this and you would still end up with a perfectly valid router / working app:

import { Router, Route } from '@redwoodjs/router'
const Ping = () => console.log("pong")

const Routes = () => {
  return (
    <Router>
      <Route path="/login" page={LoginPage} name="login" />
      <Ping path="/orders" page={OrdersPage} name="orders" />
      <Ping path="/orders/{id:Int}" page={OrderPage} name="order" />
      <Ping path="/orders/{id:Int}/edit" page={EditOrderPage} name="editOrder" />
      <Ping path="/orders/new" page={NewOrderPage} name="newOrder" />
      <Route path="/" page={HomePage} name="home" />
      <Route notfound page={NotFoundPage} />
    </Router>
  )
}

In fact, the function ping will never be called and you won't see any "pong" logged to the console. This may be obvious to people experienced in how routers are implemented but it was a shock to me! Further, this made it impossible for me to implement my first idea - the traditional ProtectedRoute component, as the ProtectedRoute logic would simply never be executed. However, I'm not too disappointed here, as the solution I ended up with is also pretty straight-forward to manage (in my super humble opinion).

And that's all there is to it! At this point you should have both your authentication implemented and your sensitive Redwood routes protected. If there are any pro Redwood users already out there that have some corrections / best practices to add to this discussion - please reach out / comment!

But most importantly - stay safe and healthy everyone!!

Using Bitmapist for Super Fast Analytics

tmns — Sat, 25 Jan 2020 15:59:34 +0000

Background

Let's say we have built a CRM application, which keeps track of the various metadata logged by users when they use one of our other apps. For example this data could be that the user is using an iPhone, that they have logged in, or that they are within the age range of 30-40.

If we have millions of users and consequently millions of pieces of metadata - what is an efficient way for us to find groups of our users that meet certain criteria (also called cohorts)? For example, say we want to send a newsletter out to all of our users who are within the age range of 30-40 and who have logged in today - how do we determine this group of users?

One solution that tends to be very memory-efficient is to use Redis bitmaps. The concept of bitmaps, specifically in regards to Redis, has been explained rather thoroughly quite a few times already so I won't go into depth here. If you are hungry for all the juicy details - I suggest the following well-known articles as a good place to start:

The tl;dr though, is that every time a user registers and lets us know they are in the age range of 30-40, we can set a key-value pair in Redis like so: SETBIT('agerange#3040', user_id, 1).

Similarly, once the user logs in, we can set another key-value pair: SETBIT('login:today', user_id, 1).

Then, finding the cohort becomes a matter of performing a bitwise AND operation on the two keys, like so: BITOP('AND', '3040logintoday', 'agerange#3040', 'login:today')

And just like that we have determined all the users we want to send our newsletter to!

At this point, you may be saying something along the lines of, "Ya, that's nice and all but Redis.. Bitmaps.. keys.. values.. Bitwise operations.. my head hurts already!". This is a totally understandable reaction - with a totally awesome rebuttal. Enter Bitmapist.

Bitmapist

Bitmapist is a Python library developed by the folks at Doist that simplifies working with Redis bitmaps. Further, they have even gone as far as also developing their own optimized Bitmapist server that implements a subset of Redis operations used by Bitmapist while relying on compressed bitmaps representation and only keeping hot dataset in memory to improve memory efficiency by 443 times!

What does setting all this up look like? Let's give it a spin!

First, let's install the bitmapist server

$ git clone https://github.com/Doist/bitmapist-server.git
$ cd bitmapist-server
$ go build
go: downloading github.com/artyom/autoflags v1.1.0
go: downloading github.com/artyom/resp v1.0.0
go: downloading github.com/golang/snappy v0.0.1
[...]

Once go finishes building the server, you should see a bitmapist-server executable in the same directory. You can run it as it is, or supply an optional -addr option if you want it to listen somewhere other than the default localhost:6379. Running the executable should result in some output like so:

$ ./bitmapist_server
2020/01/25 15:22:09 loading data from bitmapist.db
2020/01/25 15:22:09 loaded in 4.922263ms
2020/01/25 15:25:09 periodic saving...
2020/01/25 15:25:09 saved in 11ms

At this point you have your bitmapist server all set up! You can even use redis-cli to connect to it:

$ redis-cli
127.0.0.1:6379> keys **
(empty list or set)

As we can see, we don't have any data in our server yet - let's change that by installing and running Bitmapist!

$ pip install redis bitmapist4
$ python
>>> import bitmapist4
>>> b = bitmapist4.Bitmapist('redis://localhost:6379', key_prefix='bitmapist__')

The key_prefix parameter above ensures that every key you set with this session will be prepended with the value you choose, in this case bitmapist__. We currently use this functionality as a means of compartmentalizing different applications. That is, we set the key_prefix to be the application's uuid so that way we only deal with that application's data (key-value pairs when we perform our Bitmapist routines.

Let's perform the keys ** equivalent in Bitmapist:

>>> b.get_event_names()
[]

As expected, it's simply an empty list. Let's mark some events!

>>> b.mark_unique('agerange#3040', 1)
>>> b.mark_unique('agerange#3040', 2)
>>> b.mark_unique('agerange#2030', 3)
>>> b.mark_event('login', 1)
>>> b.get_event_names()
['_agerange#2030', '_agerange#3040', '_login']

So now we've told our server that user 1 and 2 is within the age of 30 and 40, user 3 is within the age of 20 and 30, and user 1 has logged in today. On the redis-cli side, keys ** now returns:

127.0.0.1:6379> keys **
1) "bitmapist__agerange#2030"
2) "bitmapist__agerange#3040"
3) "bitmapist__login_2020-1"
4) "bitmapist__login_W2020-4"
5) "bitmapist__login_2020-1-25"
6) "bitmapist__login"

You may be wondering why there are extra keys in our server and also why we only stored the key login and not login:today. The answer to both these questions is part of what makes Bitmapist so awesome. When using mark_event(), Bitmapist automatically stores a key with just the event name, a key with the event name and with appended date values for the current day, week, month, and year.

This in turn allows you to perform calls such as the following to find out if an event has taken place within a certain time period:

>>> b.YearEvents('login')
YearEvents("login", 2020)
>>> b.MonthEvents('login')
MonthEvents("login", 2020, 1)
>>> b.WeekEvents('login')
weekEvents("login", 2020, 4)
>>> b.DayEvents('login')
DayEvents("login", 2020, 1, 25)
>>> b.HourEvents('login')
HourEvents("login", 2020, 1, 25, 15)

This is great, as it significantly decreases our mental load when creating and managing our keys. Now, going back to our original problem, let's find all our users who are in within the age range of 30 and 40 and who have logged in today:

>>> cohort = b.BitOpAnd(b.UniqueEvents('agerange#3040'), b.DayEvents('login'))
>>> for user in cohort:
...    print(user)
1

Okay, so it turns out we will only be sending our newsletter to user 1 today, which is a bit anticlimactic.. BUT the cool thing to note here is that Bitmapist also provides bitwise operation helper functions, such as BitOpAnd used above. Alternatively, you can also use the operator itself like so:

>>> cohort = b.UniqueEvents('agerange#3040') & b.DayEvents('login')

Pretty cool, eh? That's really just the tip of the iceberg though; check out the project's github page for more examples and features, like the cohort table!

Bonus

What if you've read the gitub page, scoured the source code, and still feel like Bitmapist is missing something? Luckily, the people behind it seem to be pretty into clean and organized code, because customizing it is a breeze.

For example, we have use cases where we need to calculate populations of users like so:

How many users were using an android device between the dates of 16-01-20 and 19-01-20?
How many users were using an ios device between February and May?

Bitmapist doesn't provide a class to handle this type of event search, so I added my own! I accomplished this by editing only two of the project's files: bitmapist4/events.py and bitmapist4/core.py. First, in events.py:

class RollingEvents(BaseEvents):
    """
    Events over a specified amount of time.

    Example:

        date = datetime.strptime('19-02-19', '%d-%m-%y')
        RollingEvents('event_name', 'day', date, 36)
    """

    def __init__(self, event_name, scale, dt=None, delta=0):
        self.event_name = event_name
        self.scale = scale
        self.dt = dt or datetime.datetime.utcnow()
        self.delta = delta

        events = []
        if scale == 'day':
            events.append(self.bitmapist.DayEvents.from_date(event_name, dt))
            for i in range(delta):
                events.append(self.bitmapist.DayEvents.from_date(event_name, dt).delta(-(i + 1)))
        elif scale == 'week':
            events.append(self.bitmapist.WeekEvents.from_date(event_name, dt))
            for i in range(delta):
                events.append(self.bitmapist.WeekEvents.from_date(event_name, dt).detla(-(i + 1)))
        elif scale == 'month':
            events.append(self.bitmapist.MonthEvents.from_date(event_name, dt))
            for i in range(delta):
                events.append(self.bitmapist.MonthEvents.from_date(event_name, dt).delta(-(i + 1)))
        elif scale == 'year':
            events.append(self.bitmapist.YearEvents.from_date(event_name, dt))
            for i in range(delta):
                events.append(self.bitmapist.YearEvents.from_date(event_name, dt).delta(-(i + 1)))
        if events:
            if len(events) == 1:
                self.redis_key = events[0].redis_key
            else:
                or_op = self.bitmapist.BitOpOr(*events)
                self.redis_key = or_op.redis_key
[...]

Then, in core.py:

class Bitmapist(object):
[...]
    def __init__(self,
[...]
        kw = {'bitmapist': self}
        self.UniqueEvents = type('UniqueEvents', (ev.UniqueEvents, ),
                                  kw)  # type: Type[ev.UniqueEvents]
        self.RollingEvents = type('RollingEvents', (ev.RollingEvents, ),
                                  kw) # type; Type[ev.RollingEvents]
[...]

With those changes, I could solve the first problem mentioned above by using the RollingEvents class like I do any other:

>>> len(b.DayEvents('os:android').delta(-6))
66
>>> len(b.DayEvents('os:android').delta(-7))
240
>>> len(b.DayEvents('os:android').delta(-8))
319
>>> len(b.DayEvents('os:android').delta(-9))
255
>>> six_days_ago = datetime.datetime.utcnow() - datetime.timedelta(6)
>>> len(b.RollingEvents('os:android', 'day', six_days_ago, 3))
880

Great success!

Conclusion

Bitmapist and the Bitmapist server both make reasoning about and implementing bitmap-based datasets straight-forward and fun. They also lower the knowledge barrier required to start experimenting with such datasets, as they abstract away all the Redis commands that are typically quite daunting to newcomers.

Further, they are written well and comprise code easy to navigate, which provides for quick customization if needed.

Keep up the great work Doist!

Making Ember Addons Fastboot Compatible

tmns — Tue, 03 Dec 2019 16:29:56 +0000

Intro

Hello to the 30 people out there who still use Ember 👋🐿

Just kidding - I know the number is higher than 30, but in a world dominated by React, Angular, and Vue, it seems like we who develop with Ember (either by choice [really?!?] or by career happenstance), are pretty alone - especially in terms of useful and helpful material.

That's part of the reason why when faced with the task of adding Fastboot (Ember's version of server-side rendering) to a project riddled with jQuery, along with the demand that all the jQuery remain functional, it took me quite a heavy amount of blood, sweat, and tears to get things working.

As such, I'll share here a nice little trick I learned along the way in case any other poor soul finds themself in the dark shadows that is Ember Fastboot development.

What's the issue?

When adding Fastboot to an Ember project that makes heavy use of addons that in turn utilize third-party client-side JS libraries (typically jQuery), you will quickly find out that your project will have a hard time rendering on the server if you don't make some drastic changes. This is simply due to the project being unable to build and render client-side JS within the server (ie node) environment.

This leaves us with a few options. First, we can simply gut all the incompatible client-side JS logic and / or use node-compatible equivalents. A common example of this is using ember-fetch instead of jQuery.ajax. Second, we can hope that the maintainer(s) of the addon in question has taken notice of the Fastboot issue and made their library Fastboot compatible.

Unfortunately, there are inherent problems with both of these options. First, often a node-compatible equivalent simply doesn't exist. Second, often the maintainer of a library's idea of making their library Fastboot compatible looks something like this:

    if (process.env.EMBER_CLI_FASTBOOT) {
        return;
    }

...which, aside from being broken (this test always fails, as EMBER_CLI_FASTBOOT does not exist in process.env as far as I can tell), essentially only does one thing - which is to simply not import the library into the application. This means that when the app finally makes it to the browser, the library will not be there 😑

We want the best of both worlds. We want the offending addon to be loaded into Fastboot but its client-side code not evaluated until it reaches the browser.

What's the solution?

The most streamlined and bulletproof solution I've found so far is acting as if you yourself are the maintainer of the library. In essence, you must become one with the maintainer and realign the inner zen of the library - also known as making some changes to the library's index.js 😁

As noted in the Fastboot Addon Author Guide, if your addon includes third-party code that is incompatible with node / Fastboot, you can add a guard to your index.js that ensures it is only included in the browser build. This is achieved by creating separate build tree specifically for the browser.

Unfortunately, the Fastboot guide falls short in its given example of actually implementing such a guard. So we will give a more thorough and real-world example here.

Being Slick(er)

Let's say we want to use the addon ember-cli-slick, which is essentially an Ember port of the Slick Slider plugin. The addon's index.js looks like this:

    'use strict';

    const path = require('path');

    module.exports = {
      name: require('./package').name,

      blueprintsPath: function() {
        return path.join(__dirname, 'blueprints');
      },

      included: function(app) {
        this._super.included(app);

        app.import('node_modules/slick-carousel/slick/slick.js');
        app.import('node_modules/slick-carousel/slick/slick.css');
        app.import('node_modules/slick-carousel/slick/slick-theme.css');
        app.import('node_modules/slick-carousel/slick/fonts/slick.ttf', { destDir: 'assets/fonts' });
        app.import('node_modules/slick-carousel/slick/fonts/slick.svg', { destDir: 'assets/fonts' });
        app.import('node_modules/slick-carousel/slick/fonts/slick.eot', { destDir: 'assets/fonts' });
        app.import('node_modules/slick-carousel/slick/fonts/slick.woff', { destDir: 'assets/fonts' });
        app.import('node_modules/slick-carousel/slick/ajax-loader.gif', { destDir: 'assets' });
      }
    };

If you look closely, you will see that the first import being made is slick.js. This is awful for Fastboot and will cause it to blow up server-side. So how do we make slick a little more slicker with its imports?

The first step is getting rid of the blueprintsPath and creating a separate import tree for our offending code, which we will term as vendor code. Let's write out the function and import our necessary objects:

    module.exports = {
      name: 'ember-cli-slicker',

      treeForVendor(defaultTree) {        
        const map = require("broccoli-stew").map;
        const Funnel = require("broccoli-funnel");
        const mergeTrees = require('broccoli-merge-trees');
      },

        included: function(app) {
        [...]

Now, let's use the Funnel object to specify the code we want to separate:

    module.exports = {
      name: 'ember-cli-slicker',

      treeForVendor(defaultTree) {        
        const map = require("broccoli-stew").map;
        const Funnel = require("broccoli-funnel");
        const mergeTrees = require('broccoli-merge-trees');

            let browserVendorLib = new Funnel('node_modules/slick-carousel/slick/', {
          destDir: 'slick',
          files: ['slick.js']
        })
      },

        included: function(app) {
        [...]

Next, we define the guard that is mentioned in the Fastboot documentation, which essentially states to only include our code if the FastBoot object is undefined, which is guaranteed to be true when we are in the browser:

    module.exports = {
      name: 'ember-cli-slicker',

      treeForVendor(defaultTree) {        
        const map = require("broccoli-stew").map;
        const Funnel = require("broccoli-funnel");
        const mergeTrees = require('broccoli-merge-trees');

            let browserVendorLib = new Funnel('node_modules/slick-carousel/slick/', {
          destDir: 'slick',
          files: ['slick.js']
        })

            browserVendorLib = map(browserVendorLib, (content) => `if (typeof FastBoot === 'undefined') { ${content} }`);
        },

        included: function(app) {
        [...]

Then, to wrap up the separation, we return a merge of both the defaultTree and our browser / vendor tree:

    module.exports = {
      name: 'ember-cli-slicker',

      treeForVendor(defaultTree) {        
        const map = require("broccoli-stew").map;
        const Funnel = require("broccoli-funnel");
        const mergeTrees = require('broccoli-merge-trees');

            let browserVendorLib = new Funnel('node_modules/slick-carousel/slick/', {
          destDir: 'slick',
          files: ['slick.js']
        })

            browserVendorLib = map(browserVendorLib, (content) => `if (typeof FastBoot === 'undefined') { ${content} }`);

            return new mergeTrees([defaultTree, browserVendorLib]);
        },

        included: function(app) {
        [...]

But wait!! This also has the potential to fail - as it is actually possible for defaulTree to be undefined! So, we must guard against this by only including it if it exists:

    module.exports = {
      name: 'ember-cli-slicker',

      treeForVendor(defaultTree) {        
        const map = require("broccoli-stew").map;
        const Funnel = require("broccoli-funnel");
        const mergeTrees = require('broccoli-merge-trees');

            let browserVendorLib = new Funnel('node_modules/slick-carousel/slick/', {
          destDir: 'slick',
          files: ['slick.js']
        })

            browserVendorLib = map(browserVendorLib, (content) => `if (typeof FastBoot === 'undefined') { ${content} }`);

            let nodes = [browserVendorLib];
            if (defaultTree) {
                nodes.unshift(defaultTree);
            }

        return new mergeTrees(nodes);
        },

        included: function(app) {
        [...]

The next step is correcting the app import statement in included. We want to change the import statement to point at our new vendor/slick/ directory. In our case this looks like:

        [...]
      included: function(app) {
        this._super.included(app);

        app.import("node_modules/slick-carousel/slick/slick.css");
        app.import("node_modules/slick-carousel/slick/slick-theme.css");
        app.import("node_modules/slick-carousel/slick/fonts/slick.ttf", {
          destDir: "assets/fonts"
        });
        app.import("node_modules/slick-carousel/slick/fonts/slick.svg", {
          destDir: "assets/fonts"
        });
        app.import("node_modules/slick-carousel/slick/fonts/slick.eot", {
          destDir: "assets/fonts"
        });
        app.import("node_modules/slick-carousel/slick/fonts/slick.woff", {
          destDir: "assets/fonts"
        });
        app.import("node_modules/slick-carousel/slick/ajax-loader.gif", {
          destDir: "assets"
        });

        app.import("vendor/slick/slick.js");
      }
    };

And finally, the obligatory code snippet of everything put together:

    'use strict';

    module.exports = {
      name: 'ember-cli-slicker',

      treeForVendor(defaultTree) {        
        const map = require("broccoli-stew").map;
        const Funnel = require("broccoli-funnel");
        const mergeTrees = require('broccoli-merge-trees');

        let browserVendorLib = new Funnel('node_modules/slick-carousel/slick/', {
          destDir: 'slick',
          files: ['slick.js']
        })

        browserVendorLib = map(browserVendorLib, (content) => `if (typeof FastBoot === 'undefined') { ${content} }`);

            let nodes = [browserVendorLib];
            if (defaultTree) {
                nodes.unshift(defaultTree);
            }

        return new mergeTrees(nodes);
      },

      included: function(app) {
        this._super.included(app);

        app.import("node_modules/slick-carousel/slick/slick.css");
        app.import("node_modules/slick-carousel/slick/slick-theme.css");
        app.import("node_modules/slick-carousel/slick/fonts/slick.ttf", {
          destDir: "assets/fonts"
        });
        app.import("node_modules/slick-carousel/slick/fonts/slick.svg", {
          destDir: "assets/fonts"
        });
        app.import("node_modules/slick-carousel/slick/fonts/slick.eot", {
          destDir: "assets/fonts"
        });
        app.import("node_modules/slick-carousel/slick/fonts/slick.woff", {
          destDir: "assets/fonts"
        });
        app.import("node_modules/slick-carousel/slick/ajax-loader.gif", {
          destDir: "assets"
        });

        app.import("vendor/slick/slick.js");
      }
    };

And that's it! We now can successfully include ember-slick into our server-side rendered Ember project, deferring its evaluation until it reaches the browser and in turn avoiding any fatal errors during the process - which is quite a feat for anyone that's dealt with Ember Fastboot and fancy browser JS addons 🥳

Conclusion

While it's quite a cold, dark world out there for Ember developers nowadays, there are still some glints of light and hope here and there. One such glint is the realization that including client-side JS heavy addons into a Fastboot project is indeed possible and can be achieved by editing the addon's index.js.

I hope this helps the 29 others out there that may be facing similar issues 😉

My perilous undefined cookie in Heroku

tmns — Mon, 05 Aug 2019 14:38:05 +0000

Lately I've been working on a client-side encrypted password manager, built with React and Express, which you can play around with here.

The other day I came to the point where I felt it was time to deploy to Heroku. As usual, things were working fine in my local environment but everything crashed and burned once trying to run the app in prod. Debug time!!

What exactly was the problem? The app would build and start fine; however, whenever I would attempt to navigate to the app it would immediately crash - serving the standard 500 application error Heroku page. I immediately checked the app's logs and saw an error I hadn't previously seen:

/app/node_modules/express-session/session/session.js:59
  this.cookie.maxAge = this.cookie.originalMaxAge;

TypeError: Cannot read property 'originalMaxAge' of undefined
    at Session.resetMaxAge (/app/node_modules/express-session/session/ session.js:59:36)
    at Session.touch (/app/node_modules/express-session/session/ session.js:48:15)
    at ServerResponse.end (/app/node_modules/express-session/index.js:326:21)
    at Array.write (/app/node_modules/finalhandler/index.js:297:9)
    at listener (/app/node_modules/on-finished/index.js:169:15)
    at onFinish (/app/node_modules/on-finished/index.js:100:5)
    at callback (/app/node_modules/ee-first/index.js:55:10)
    at IncomingMessage.onevent (/app/node_modules/ee-first/index.js:93:5)
    at IncomingMessage.emit (events.js:203:15)
    at endReadableNT (_stream_readable.js:1145:12)
    at process._tickCallback (internal/process/next_tick.js:63:19)
npm ERR! code ELIFECYCLE
npm ERR! errno 1

this.cookie is undefined! How? What? When? WHY?

When I see a cookie error in this context, my mind goes directly to the common CORS, secure, and proxy trust pitfalls that are easy to fall into / not get quite right when working with session handling in Express. Thus I checked all such related code, changed it around, flipped booleans off and on, etc. But no dice...

Next I began to research the error to see if anyone else had ran into the same problem. I found some similar results but nothing quite the same. Further, most of the answers suggested playing around with CORS and the likes - a road I had already gone down quite exhaustively. In one post, a person stated that they had accidentally set the maxAge property of their cookie to a value that more or less expired immediately. I double-checked the value I had set in my server's config.js file:

export const {
  PORT = 4000,
  PROTO = 'http',
  HOST = 'localhost',
  DB_NAME = 'keySafeDB',
  DB_URI = 'mongodb://localhost:27017/keySafeDB',
  SESS_NAME = 'sessionId',
  SESS_SECRET = 'test-secret',
  SESS_LIFETIME = 1000 * 60 * 60
} = process.env;

Looked fine! But I was also setting SESS_LIFETIME as a config variable in Heroku's settings. So I checked there as well:

SESS_LIFETIME = 1000 * 60 * 60 * 24

That also looked fine! So what could it possibly be?? I decided to turn on express-session debugging to see if it would provide me with any useful info. Starting the app this time with DEBUG=express-session, the app also printed out this little gem:

express-session no SID sent, generating session

Okay, so not a whole lot of info there, but maybe I should dig into the source of express-session and see where that line is being printed out from, what the state of the app should be around that time, and how exactly the error itself ties into this context. Looking at express-session/index.js, I found the string here:

    // generate a session if the browser doesn't send a sessionID
    if (!req.sessionID) {
      debug('no SID sent, generating session');
      generate();
      next();
      return;
    }

Unfortunately, looking into the generate function didn't lead me to any new revelations. Since I was in the source already, I decided to also check out the origin of the error itself, in express-session/session/session.js but this also didn't open my eyes to anything groundbreaking.

So, I was at a lost. Since I had exhausted pretty much every possible point of error I could think of, I decided it was an appropriate time to ask around for help. I posted my plea in some Discord communities but unfortunately, since the error was seemingly so obscure, nobody had any real insight to offer.

So I decided I'd take my issue directly to the source itself and open a Github issue. I opened up the new issue form but stopped before writing. Something in me told me I should play around a liiiiittle bit more before taking such a drastic measure. Something I could still do, I thought, would be to remove some of the cookie-related config variables I had set in Heroku's settings and just use the ones I had hardcoded in the config.js file. After all, the app worked fine when using it locally and the main values that changed between environments were the values of these variables.

I started by deleting the config variable SESS_LIFETIME. I then attempted to open the app and......

....

it worked!

But why??! Was that really it the whole time?? The only difference between the SESS_LIFETIME value in the Heroku settings and in the local config.js file was the additional multiplication of 24, to get the cookie to last a day: 1000 * 60 * 60 * 24. Had I forgotten how to multiply and was actually fudging this equation completely? I set the value in the config.js file also to 1000 * 60 * 60 * 24 and re-deployed. The app still worked!! What?!!

I then reset the config variable in Heroku and the app went back to crashing immediately. So in the end this little config variable was the culprit all along! Ouch! And double ouch considering it wasn't even really necessary.

I checked out the Heroku docs and didn't find anything about restrictions on what a config variable value can contain. I also set the value to a simple integer and this also caused the application to crash. You would think this would be documented somewhere. Or maybe it's just well-known that Heroku's config variables can only be strings? If anyone has some insight there it would be appreciated!

But the main point of this article is to simply warn anyone that may be seeing a similar error - check out your config variables first! It might save you a few days (ahem.. I totally mean hours..) of unproductive troubleshooting :)

Chatting with Sapper (Svelte) and Socket.IO

tmns — Wed, 24 Jul 2019 07:57:17 +0000

Context

While working on my last project, a spaced repetition learning app (play with the demo here), I stumbled upon Svelte, a component framework that runs at build time and compiles your code into optimized, vanilla JS. I played with the tutorial a bit and it seemed really fun. I also quickly discovered Sapper, an application framework for building Svelte apps. So, I decided the next project I would do would be something small to help me learn about Svelte / Sapper.

In addition to Svelte, I also wanted to test out Socket.IO, a library that enables real-time, bidirectional, event-based communication between a client and server. So, I thought a good way to combine the two would be to build a simple chat application. I also felt that something like this could not only be a great way to personally learn something about these technologies but also an example that could be used to teach others (eg in a workshop, meetup, course, etc). As such I will write a little about how I found the app building process below. For the impatient, you can go directly to the app's repo or play around with the demo.

Setting Up

Getting up and running was rather painless and really as simple as the Sapper docs imply. With the following sequence of commands I had a new Sapper project ready to be worked on:

npx degit "sveltejs/sapper-template#rollup" chat-app
cd chat-app
npm install

The next step was to install the Socket.IO essentials. This was easy enough with npm install --save socket.io. However, one gotchya I encountered was that I couldn't get my index.svelte to properly import the io object from the standalone client build exposed by the server by default at /socket.io/socket.io.js. This could be due to a race condition in how all resources are loaded. So, I instead opted to import the package node_modules, but this resulted in a module not found error for bufferutil.

Finally, I realized that if I wanted to go that route I also had to explicitly install the client package: npm install --save socket.io-client. While this is not mentioned in the getting started docs, it is mentioned in the extended docs (doh!!!). Another alternative would be to try to load from the CDN, but I didn't try this. Once I installed the client package, I was able to import it into my index.svelte and begin using the io object!

Building out the server

The Socket.IO docs are great but they deal explicitly with Express. I like and know Express rather well, but I had never tried Polka before and since it comes with Sapper by default I thought it would be a perfect time to give it a try. Luckily, the Polka people (or person it seems?) also wrote an example (a chat application nonetheless!) specifically showcasing how to use it was Socket.IO; so, I was able to lean on it quite heavily for guidance.

Check it out here. It's really all you need to get going. So instead of going over it redundantly here, I will simply refer to relevant server code as I explain different parts of the client below.

Building out the client

The client simply consists of an index.svelte page and a Heading.svelte component. I decided to abstract out the heading to its own component in case I wanted to use it on other pages or even in other projects. To achieve something like this with Svelte is very easy; for example, my Heading.svelte looks like so:

<style>
  [...CSS...]
</style>

<script>
  export let text;
</script>

<div id="heading">{text}</div>

Then, in index.svelte, it is utilized like so:

<script>
  import Heading from '../components/Heading.svelte';

  [...]
</script>

<body>
  <div class="main">
    <Heading text={'Chat App'} />
  [...]
</body>

It should also be noted that you can set a default value for text in Heading.svelte by simply assigning it to a value rather than leaving it undefined.

The chat functionality itself is mainly handled by various Socket.IO socket.on and socket.emit (or socket.broadcast.emit) calls that are fired in response to user actions. For example, to implement message sending, we first add an event listener to the app's send button, which is achieved very easily with Svelte:

<form action="">
  <input id="m" autocomplete="off" {placeholder} bind:value={message} />
  <button on:click|preventDefault={handleSubmit}>Send</button>
</form>

Note also that we are binding the value of the message input field to the variable message. This will create a two-way binding and make sure whatever is typed into the field is automatically bound to our message variable defined in our script block (via something like the usual let message = '').

When the user clicks the send button then, our function handleSubmit, also defined in our script block, will be called. Within it, we first add it to a messages array, which acts as our data structure for storing all messages of a given session and then we emit a 'message' event:

messages = messages.concat(message);
socket.emit('message', message);

Then, on the server side, we have a listener that will listen for such events and react accordingly whenever it receives one. In our case, that simply means broadcasting the message to all users (except the user that sent it):

socket.on('message', function(message) {
  socket.broadcast.emit('message', message);
})

And finally, back in our script block of index.svelte, we have another socket.on listener waiting to receive such 'message' events so it can add them to the messages array and display them in the chat window:

socket.on('message', function(message) {        
  messages = messages.concat(message);
});

At this point, you're probably thinking: 'okay, that's nice, but how do we display the messages to the user?'. Again, Svelte makes this very easy. With the help of Svelte's #each block functionality, we can simply create a list element via ul and then populate it with an li element for each message in messages:

<div id="chatWindow">
  <ul id="messages">
    {#each messages as message}
      <li>{message}</li>
    {/each}
  </ul>
</div>

Cool, now each time a new message is added to messages, the chat window is updated and displays it instantly! It would be nice for the new message to fade in though, rather than suddenly appear. Time for some CSS or extra JavaScript right? Nope, Svelte to the rescue:

<li transition:fade>{message}</li>

Yup, that's really all that's needed to add a nice fade-in transition to each message. Further, at this point, that's all you really need to have a working chat client! I could have also stopped here but I wanted to add a few little extras, one of which was a message informing the user of how many users total were currently chatting.

This ended up being a little tricky because I wasn't sure where to store and update this value. Svelte itself implements an app-wide store; however, this proved to not be the correct solution, as I needed something that would be updated for every client every time a new user connected. The solution thus ended up being to store the value server-side, and then on every new 'connection' event, update the value and send it back to the client, which would then update its local copy accordingly. First the server code:

[...]
let numUsers = 0;

io(server).on('connection', function(socket) {
  ++numUsers;
  let message = 'Server: A new user has joined the chat';
  socket.emit('user joined', { message, numUsers });
  socket.broadcast.emit('user joined', { message, numUsers });
[...]

Note that we must call both socket.emit (which sends a message back to the user who sent the event) and socket.broadcast.emit (which sends a message to all users except the user who sent the event). This is because we want both the user who joined and all other users to receive this event and have the correct number of users locally stored.

Then, back on the client in our script block, we set up our local variable to store the number of users connected and our listener for the 'user joined' event:

let numUsersConnected = 0;
[...]
socket.on("user joined", function({message, numUsers}) {
  messages = messages.concat(message);
  numUsersConnected = numUsers;
  updateScroll();
});
[...]

And finally, down in our html we insert our data as such:

<p>There {numUsersConnected == 1 ? 'is' : 'are'} {numUsersConnected} {numUsersConnected == 1 ? 'user' : 'users'} currently chatting!</p>

You may have noticed in the listener above that we also make a call to a function called updateScroll. This is simply a function that auto-scrolls the chat window on each new message:

function updateScroll() {
  const chatWindow = document.getElementById('chatWindow');
  chatWindow.scrollTop = chatWindow.scrollHeight;   
}

The gotchya I encountered with this though was that every time this function would call, the chat window would auto-scroll, but not all the way to the bottom of the div. Instead, it would scroll just above the last sent message, so the user would always have to scroll a little bit more to reveal the latest message. What could be causing this weird bug??

I finally realized that this was due to a little race condition. Essentially, the updateScroll function was being called before the new message was actually being added to the DOM, resulting in the scrollTop always being set to just above the latest message! To fix this, I simply threw the scrollTop assignment into a setTimeout callback so it would be handled by the web API and be forced to wait in the job queue until all other code had been executed:

function updateScroll() {
  const chatWindow = document.getElementById('chatWindow');
  setTimeout(() => {
    chatWindow.scrollTop = chatWindow.scrollHeight; 
  }, 0);
}

And with that the scroll began working perfectly!

A final gotchya you may encounter when working with Svelte is that if you attempt to add an event listener to the window object you will get a ReferenceError: window is not defined upon execution. This is also due to a race condition; however, Svelte documents this and provides a simple way to interact with the window object via a special svelte:window element. In this app, the element was utilized to call a function whenever the window unloaded:

<svelte:window on:unload={emitUserDisconnect}

And just like that you not only have access to the window object but can also easily set up event listeners!

Conclusion

This was a really quick and fun starter project to get familiar with Svelte / Sapper and Socket.IO. I think it would make for a great project to implement together with others in an afternoon knowledge-sharing session (eg a meetup). While there are definitely a few gotchyas, once you truly understand the problem you typically find that they are actually already documented and a clean solution exists. I suggest you give these technologies a try; both make developing rather painless and perhaps more importantly- very fun!

Forem: tmns

useSelectInnerText: Cross-browser solution for selecting inner text

What's the issue?

What can we do?

What's the catch?

Conclusion

Code-splitting in React WITHOUT Suspense: useLazyLoad

tl;smtc (too long; show me the code)

Okay, what's this all about?

So, what is to be done?

🪝🪝🪝

Conclusion

Note on React 18 and useTransition

Creating better user experiences with React 18 Suspense and Transitions

What are you talking about?

How does it work?

Setup

Suspense (for data fetching)

Transitions

That's all folks

YouTube iframe, shadows, rounded corners, and Safari

Context

Approach #1: border-radius

Approach #2: clip-path and filter: drop-shadow()

Approach #3: ?

Conclusion

Update / Approach #4

useCancelToken: a custom React hook for cancelling Axios requests

Update

What's the problem?

What can we do about it?

Hook, line, something something..

Conclusion

11ty Feedback: A starter project for exchanging meaningful feedback

What's all this ruckus?

So...

How?

Build a Responsive Nav BBC & Smashing Magazine Style!!

Context

Adding some HTML & CSS

Adding some JS

Adding some IntersectionObserver

Conclusion

Adding Authentication to RedwoodJS (the hard way)

What?

How?

Using Bitmapist for Super Fast Analytics

Background

Bitmapist

Bonus

Conclusion

Making Ember Addons Fastboot Compatible

Intro

What's the issue?

What's the solution?

Being Slick(er)

Conclusion

My perilous undefined cookie in Heroku

Chatting with Sapper (Svelte) and Socket.IO

Context

Setting Up

Building out the server

Building out the client

Conclusion

Note on React 18 and `useTransition`

Approach #1: `border-radius`

Approach #2: `clip-path` and `filter: drop-shadow()`

Adding some `IntersectionObserver`