DEV Community: Per Enström

Four tricky JavaScript concepts in one line of code

Per Enström — Fri, 10 Dec 2021 14:09:35 +0000

My colleague approached me the other day with a line of JavaScript code he had found on Stack Overflow, and asked how it worked. And I thought it was such a good example of four mid to advanced concepts in JavaScript so I decided to write down my explanation here as well.

The line in question is this

const result = (({ a, c }) => 
  ({ a, c }))({ a: 1, b: 2, c: 3, d: 4 });

Before reading on, give it a think and see if you can work it out by yourself.

Ready to go on? Let’s go.

Object destructuring

Documentation at MDN

Object destructuring is the concept of picking properties from an object in batch instead of manually accessing each property and assigning them to a variable. Say you have an object coming in as a parameter in some function, and you want to do stuff with only a few of the properties of that object. Object destructuring makes that possible.

Instead of doing

const a = myObject.a;
const b = myObject.b;

doStuff(a, b);

we can shorten it to

const { a, b } = myObject;

doStuff(a, b);

which does the same thing. This makes the code much smaller, especially when we do stuff to multiple properties of an object. This saves us writing the full property path every time.

The fancy stuff here is that this sort of destructuring works anywhere we have an object. Even when assigning input parameters for a function. So

const myFunction = (myObject) => {
  console.log(myObject.a);
  console.log(myObject.b);
};

can be written as

const myFunction = ({ a, b }) => {
  console.log(a);
  console.log(b);
};

Object shorthand form

Documentation at MDN

When composing objects, we often have incoming parameters from somewhere, and transform them and then return a new object. This can often look like this:

const someDescriptiveName = doStuff(a);
const someOtherDescriptiveName = doOtherStuff(b);

const newObject = {
  someDescriptiveName: someDescriptiveName,
  someOtherDescriptiveName: someOtherDescriptiveName,
};

As you can see, this feels very repetitive. We're assigning the property with the key of a certain name with the contents of a variable with the same name. Luckily there is a shorter way of writing this.

const someDescriptiveName = doStuff(a);
const someOtherDescriptiveName = doOtherStufF(b);

const newObject = {
  someDescriptiveName,
  someOtherDescriptiveName,
};

We can just put the variable name once, and JavaScript will understand that we want a property of the same name as the variable whose value we're using.

Implicit return in arrow functions

Documentation at MDN

When an arrow method only has a return statement, it can be shortened to an implicit form. Quite often we write methods that only return a ternary, or a promise, or the result of a simple calculation. In this case, we don't need a full code block around the function content.

Instead of doing

const multiplyByTwo = (inputNumber) => {
  return inputNumber * 2;
};

we can remove the return keyword and remove the curly braces (or replace them with parentheses if returning an object literal).

const multiplyByTwo = (inputNumber) => inputNumber * 2;

Tip: In Visual Studio Code, you can put the text cursor in the middle of the arrow part of the arrow function and press cmd + . to bring up the Quick fix menu, where you can quickly add or remove the braces from the function.

Calling an anonymous function directly

Documentation at MDN

This is the least used of these four concepts. And possibly also the most confusing. It lets us invoke an arrow function immediately, without assigning it to a variable.

Instead of doing

const myLog = (text) => {
  console.log('Hello ' + text);
};
myLog('world');

we can call it directly without assigning it first

((text) => {
  console.log('hello ' + text);
})('world');

This is very rarely useful, but can be nice in some situations where you need to call an asynchronous method in a context that isn't marked as async.

Back to our confusing line

With these four parts, we can now start deconstructing the confusing line into something that makes sense. If you've already forgotten, that's alright, here it is again:

const result = (({ a, c }) => 
  ({ a, c }))({ a: 1, b: 2, c: 3, d: 4 });

We start from the back, and see that this is an arrow function that's being called immediately. Let's assign the function to a variable and call that instead.

const myFunction = ({ a, c }) => ({ a, c });

const result = myFunction({ a: 1, b: 2, c: 3, d: 4 });

Let's also move the input object to a variable to make it a bit cleaner

const myFunction = ({ a, c }) => ({ a, c });
const myObject = { a: 1, b: 2, c: 3, d: 4 };

const result = myFunction(myObject);

This is already much more readable. But let's keep going. We now direct our focus to the arrow function, where we see that we can start by adding back the curly braces and return keyword.

const myFunction = ({ a, c }) => {
  return { a, c };
};
const myObject = { a: 1, b: 2, c: 3, d: 4 };

const result = myFunction(myObject);

The next step is to remove the destructuring in the function input parameters.

const myFunction = (inputObject) => {
  const a = inputObject.a;
  const c = inputObject.c;

  return { a, c };
};
const myObject = { a: 1, b: 2, c: 3, d: 4 };

const result = myFunction(myObject);

And the final step is to remove the shorthand form of the object returned from our function.

const myFunction = (inputObject) => {
  const a = inputObject.a;
  const c = inputObject.c;

  const newObject = {
    a: a,
    c: c,
  };

  return newObject;
};
const myObject = { a: 1, b: 2, c: 3, d: 4 };

const result = myFunction(myObject);

So there we have it. We have now removed the four magic JavaScript concepts and have something that requires only basic knowledge.

When is complex too complex?

As with most of these kinds of questions, it will vary greatly between different developers and teams. But as a developer your code should always be readable without too much work. But at the same time, we cannot not use the concepts available to us in the language, we just have to know when to use them.

I would write this line as

const pickAC = ({ a, c }) => ({ a, c });
const myObject = { a: 1, b: 2, c: 3, d: 4 };

const result = pickAC(myObject);

This makes it much more readable than the one-liner, while at the same time keeping it short and concise. Calling an anonymous function immediately is a concept so rarely used that – in my opinion – it should only be used when absolutely necessary. But, to each their own, just make sure you agree amongst the team.

Migrating a Vue 2 project to Vue 3

Per Enström — Wed, 24 Nov 2021 10:36:59 +0000

In September of 2020 Evan You announced the stable release of Vue 3. The official blog post stated that it comes with

improved performance, smaller bundle sizes, better TypeScript integration, new APIs for tackling large scale use cases, and a solid foundation for long-term future iterations of the framework.

But should you take the plunge immediately and migrate all your Vue 2 projects to Vue 3? Well, it depends. For many of you, the answer is probably ‘not yet’, for others it’s a wholehearted ‘yes’.

Vue 3 doesn’t introduce anything revolutionary that you can’t already do in some fashion in Vue 2. But some features might be sufficiently attractive to upgrade. Let’s go through the four main features of Vue 3, and then you can make an informed decision yourself.

First a disclaimer. Coming from a React background, Vue is still quite new to me, and one of the reasons for embarking on the migration journey was to learn more about the inner workings. So don’t expect any deep analysis of advanced new features, and take everything with a grain of salt.

New features

Layered internal modules

This is basically a fancy way of saying that they’ve reduced tight coupling between internal parts of Vue, making them more modular and swappable. This can also result in a smaller final bundle size, since parts of the Vue runtime may be completely or partly removed during tree shaking.

These new modules also expose some of their internal APIs, which makes it possible to do some advanced solutions. One example of this is to write a custom renderer (in the blog post they mention Native or integrated systems), and the normal DOM renderer is also using these APIs.

Performance improvements

According to their own blog post, Vue 3 is up to 41% smaller, renders up to 55% faster, updates up to 133% faster and uses up to 54% less memory. However, in the migration of our product we found negligible bundle size decreases, and in some cases increases. We did not perform any speed performance testing, but my general standpoint is to trust the developers. Our project is so small from the beginning, so perhaps there wasn’t room for much savings.

Improved TypeScript integration

Vue 3 has been written completely in TypeScript, this means that all internal methods have type definitions bundled. For us developers, this means mainly that you will get some better autocompletion in VS Code, but also that moving your project to Typescript will be easier.

Composition API

Perhaps the largest change is the Composition API, which makes it possible to couple related data, methods, watches, and computations together instead of splitting the concerns over multiple parts of the component. This can make for a more elegant code base, as well as interesting possibilities for reusing parts of the logic in multiple components. See the introduction article in the Vue documentation for more information. But basically, it means we can go from this:

to this:

and then refactored to this:

Migration pattern

The complexity in migrating an existing Vue 2 project to Vue 3 entirely depends on what external plugins and libraries you are using, and how well they support Vue 3. Vue provides a migration build to ease the process, allowing you to migrate in steps while keeping some backwards compatibility. They also provide nice step-by-step instructions on how to migrate. I won’t go through it in detail here but will mention some pain points I encountered when migrating.

Notable breaking changes

Global API changes

Where you could previously access the global Vue object to, for example, add some global variables to Vue.prototype, you now have to do add it to the config object of the actual Vue instance you’re using, i.e. app.config.globalProperties.

`V-model` on custom components

When using v-model on custom components, the incoming data and emitted events have been changed. They can now be accessed on modelValue and update:modelValue. This opens up for custom components to have multiple v-model bindings.

Functional components

Functional components are now only created via a plain function and the functional attribute on single-file components have been deprecated. Where you previously used functional components to gain some performance increases, this gain is now negligible and the recommended way is to move all components to stateful components.

Render function changes

If you’re using the render function in any of your components instead of normal template components. The syntax for this has now changed.

Migration steps

The steps to complete migration can be found in the documentation, but mainly consists of:

Update Vue and add compatibility package
Fix warnings exposed by the compatibility package
Update mounting of your app
Upgrade vuex, vue-router, and any other Vue plugins you’re using
When all warnings are fixed, uninstall the compatibility package

Overall the migration is easy to follow, and all official plugins (vuex, vue-router, etc) have good migration guides as well. We noted that we used node-sass, which has been deprecated and replaced by sass, but that was an easy swap. We couldn’t go past v10 of sass-loader, since it requires Webpack 5, which is a migration for another day.

One package we used for automatic formatting of input fields, vue-mask, seemed abandoned when we migrated, but seems to be updated to Vue 3 now. But keep an eye out for packages that doesn’t support Vue 3.

Why is it not `@latest`?

If you’ve looked into Vue 3, you might have found that (at the time of writing) the @latest tag on NPM still points to Vue 2, with Vue 3 being relegated to @next still. Even though Vue 3 was released in 2020, they are holding up on pointing everyone to the latest version until more plugins have been migrated to support Vue 3. Since Vue 3 contains a number of breaking changes, if you rely on a plugin that hasn’t migrated, you’re still stuck on Vue 2.

The communication from Vue on this subject could be more transparent, however. Their roadmaps and blogposts are at this point quite outdated.

Conclusion

Should you take the plunge?

It depends. If you’re not using any of the deprecated features extensively, then I would absolutely recommend upgrading. Especially if you’re looking to moving to Typescript, the process will be easier if you’re on Vue 3. All official packages and dev tools support Vue 3, so if you use a fairly vanilla setup, the process will probably be smooth.

If you use some packages that don’t support Vue 3, and you can’t find alternatives (as we did), you will have to stay on Vue 2. That being said, if you didn’t feel like any of the new features seem interesting to you, you’re fine being on Vue 2.

But as with all projects, staying up to date has its perks. As time goes on, more and more packages will migrate to Vue 3, and eventually drop support for Vue 2, at which point you’re forced to upgrade for the same reason as you were forced to wait before.

How I made AB-testing work for our Server rendered React app and GTM+Optimize

Per Enström — Thu, 15 Jul 2021 09:50:47 +0000

Originally published on Medium 2019-10-31

So you want to be data driven? So you want to use React, GTM, Google Optimize, Server rendering and a bunch of other buzzwords currently representing the current trend of web development? So did I. And it turned out to be harder than I thought.

Edit 2020–02–04: This solution limits you to one test at the same time. We are working on a solution.

Edit 2020–09–07: I previously stated that this method only worked for one test at a time. This was due to an error in our setExperimentCookie function. We checked if there was a cookie already, and didn't set a new one if there were. When that check was removed everything worked fine. So as long as you set your experiment cookie in componentDidMount in the Experiment, it should be fine.

Edit 2020–09–07: The summary section has been rewritten to reflect our results.

But first, a short disclaimer. As with most of the articles about development you find when googling your current conundrum, this represents my solution to my specific problem with my specific tech stack. I hope you will find something to take away from this that you can apply to your problem, but most likely this will fall on the pile of articles touching near your problem, but not quite solving it. If that's the case, I wish you luck on your hunt for solutions!

* * *

Now then, what problem did I have?

The problem

We are building and managing a web site for a non profit organisation, and have recently taken over the client from a smaller team. As we like to work data driven, making decisions based on more than our hunches, we wanted to get going with AB-testing.

Symptoms

So we booted up Google Optimize and made a simple test to see if it would work. It would not. Our control variant would flicker before showing the test variant, or our variant would flicker before showing our control. And only our control variant would be shown if we navigated within the site.

Cause

The problem lay in Server rendering and our Single Page App (SPA) built in React. Our server would serve the control variant, not having any clue about any Google Optimize scripts served by Google Tag Manager (GTM) running on the site. Then either Optimize would replace the test content with the variant, and then React would hydrate the server render (thus switching back to the control), or React would hydrate and then Optimize would show the variant. Either way, the user saw flickering of different variants.

Our solution

Our solution was to build a simple custom AB-testing framework that could select variant on the server based on your session, and then adding all our test variants manually in our code instead of using Optimize's interface, and lastly sending the experiment data to Google Analytics (GA), which then Optimize will pick up and show statistics for winning variant etc.

The process of setting up an experiment is now:

Create an experiment in Optimize and as many variants as you want to test, along with the goal you want to test for
Code the different variants in the code, using the ID from Optimize
Send experiment data via a cookie to GTM, which serves it to GA and Optimize
Analyse the data in Optimize and GA

With that brief explanation, let's get into the nitty gritty.

The nitty gritty (or, actual code and stuff)

Parts of our solution are inspired by https://github.com/pushtell/react-ab-test, but we found that to be a bit too complex for our liking. And I like to know what my code does.

Selecting the variant on the server

Or actually, generating a random value between 0 and 1 for later use in variant selection.

// Set a random number between 0 and 1 based on session id
const randomFromSession = randomFromSeed(req.sessionID);

// Set it when creating our Redux store
const defaultStoreState = { ab: { cohortId: randomFromSession } };
const store = createStore(
  reducers,
  defaultStoreState,
  applyMiddleware(thunk)
);

// Send back a cookie with the cohort ID to the client in the response
res.cookie('cohortId', `${randomFromSession}`, {
  maxAge: 86400000,
  httpOnly: false
});

We're using a function to generate the random numbers, involving some maths. I wish I could give credit here, but something like it was found in an answer somewhere on stack overflow.

We save the cohort ID in our redux-store as well, to be able to get it when server rendering the experiment. Lastly we send it in a cookie back to the client.

Note that this is not an article on server rendering, I leave it to you to adapt this into your server rendering code.

The experiment code

import { Experiment, Variant } from './components/ABTesting';
import { experiments } from './config/abExperiments';

class ComponentWithExperiment extends React.Component {
  render() {
    <Experiment experimentId={experiments.testExperiment}>
      <Variant>Variant 1</Variant>
      <Variant>Variant 2</Variant>
    </Experiment>
  }
}

Remember the first step from before? There we got an experiment ID from Optimize, which we’ve here put in a config-file (exporting a simple JS object).

We send the ID as a prop to our Experiment component, and nest our variants in Variant , just for clarity. The Variant component is just rendering its children, it is only there for code readability.

Rendering the experiment

Selecting which variant is getting used is, as mentioned before, set on the server and sent to the client as a cookie. On the first server render, we read the value from the redux store. On the client side we first check the store for the value, and if it's not there we check the cookie and put it into the store for easier retrieval later.

For brevity I'm not going to include the whole file, but you can read through it all if you want. I'm going to go through parts of it here.

The constructor

  constructor(props) {
    super(props);

    // Set cohort on server and client
    let cohortId = 0;
    let cohortSet = false;
    if (
      props.cohortId !== undefined &&
      props.cohortId !== null &&
      typeof props.cohortId === 'number' &&
      Number.isFinite(props.cohortId) &&
      props.cohortId >= 0 &&
      props.cohortId < 1
    ) {
      cohortId = props.cohortId;
      cohortSet = true;
    }

    this.state = {
      cohortId,
      cohortSet
    };
  }

The constructor will be called on both the server and client, so here we check if the cohort ID is set in the redux store (and is a number between 0 and 1), and add it to the state of the component.

The componentDidMount

  componentDidMount() {
    const variantChildren = React.Children.toArray(this.props.children);
    const numberOfVariants = variantChildren.length;
    const { experimentId } = this.props;

    // Set cohort on client
    if (!this.state.cohortSet) {
      const cohortIdFromCookie = cookie.get('cohortId');
      const cohortId = cohortIdFromCookie === null ? 0 : cohortIdFromCookie;

      this.setState({ cohortId: cohortId, cohortSet: true });
      this.props.abActions.updateCohortId({ cohortId });

      this.setExperimentCookie(
        experimentId,
        this.getVariantId(cohortId, numberOfVariants)
      );
    } else {
      this.setExperimentCookie(
        experimentId,
        this.getVariantId(this.props.cohortId, numberOfVariants)
      );
    }
  }

Now, here comes a tricky part. When server rendering, we don’t have a DOM, so the components never get mounted. This means that componentDidMount only will be called on the client.

So if we’re on the client, and the cohort has not been added to the redux store yet, we read it from the cookie we got from the server, and save it in the state as well as the store.

Here we also save another cookie, containing information about both the experiment and the variant chosen on a format that Google likes (experiment.variant). This cookie will be read by GTM and pushed to GA, more on that later.

The getVariantId is just a function returning a 0-indexed number based on the number of variants and the cohort-id. You can check it out in the full file linked above.

Based on the cohort id we select one of the React children and render that and only that.

Integrating with GTM, GA, and Optimize

This is not my area of expertise, we have a partner firm that does all the setup for this. But in the process of building this, I have picked up quite a few things, and will do my best to describe them.

Page views

Since our site is a SPA, only one regular page view is being registered normally; the initial request. All subsequent navigations have to be triggered manually, either by GTM or in the code.

We have a tag in GTM for sending a page view to Google, this fires on either a normal page view trigger (initial request), or a history change trigger (all subsequent navigations). In this tag, we send a gaProperty variable along.

Experiment data

Information about what experiment and variant is displayed to a user is read from the cookie mentioned earlier and saved to two custom JavaScript variables. The custom JavaScripts read the cookie, split the value on the period, and save the correct part to itself.

These two custom variables are then added to the gaProperty variable as expId and expVar under Fields to Set in the variable settings. Sending these along with the pageview makes Google Analytics aware of any experiments running for a user in a particular session. You can then track your variant’s progress in Optimize.

In conclusion

This was our solution, I hope it can help you as well. We’re now well on our way to add AB testing to our data driven workflow. Since this article has been written we have run a few AB tests with smashing results, so this method seems to work splendidly.

Cover image by: Caleb Jones
Thanks to: Robert Källgren and Regnskog

Using Husky git hooks with GitKraken

Per Enström — Mon, 05 Jul 2021 11:23:59 +0000

Edit 2021-10-14: A fix for this in GitKraken has been released in version 7.7.2, https://support.gitkraken.com/release-notes/7x/#version-772

Utilising git hooks can be a great way of automating tasks in different parts of the git workflow. This article won’t go into detail about how git hooks work, but if you want a good starting point to learn more you can check out githooks.com, which links a lot of good resources.

A git hook is a file placed in the .git/hooks folder, and named after when in the git lifecycle it should be executed. A common way of simplifying using hooks is to install Husky, which makes the process easier and is often paired with lint-staged.

Since version 5, Husky uses a new git functionality called core.hookspath, which specifies where git should look for hooks. This gives Husky the possibility to create its hooks in a separate directory, which can be checked in and visible. However, this solution can cause problems in git clients that don’t support this feature, for example GitKraken.

To sidestep this problem we can make sure to copy the hooks to the default folder as soon as Husky is set up to make sure that clients that disregard the hookspath still can find the hooks.

By default, Husky adds a prepare script in package.json when it’s set up:

{
  ...
  "scripts": {
    ...
    "prepare": "husky install"
  }
}

This is a standard npm script that runs automatically when running npm install. If we just add a bash command to copy the installed hooks and husky file over to the standard hook folder, we fix our problem with GitKraken.

{
  ...
  "scripts": {
    ...
    "prepare": "husky install && cp -a .husky/. .git/hooks/"
  }
}

Since running npm install is an operation that all developers will start with when cloning the repository, we can make sure that we cover our bases and allow whatever git client the developer wants to use.

DEV Community: Per Enström

Four tricky JavaScript concepts in one line of code

Object destructuring

Object shorthand form

Implicit return in arrow functions

Calling an anonymous function directly

Back to our confusing line

When is complex too complex?

Migrating a Vue 2 project to Vue 3

New features

Layered internal modules

Performance improvements

Improved TypeScript integration

Composition API

Migration pattern

Notable breaking changes

Global API changes

V-model on custom components

Functional components

Render function changes

Migration steps

Why is it not @latest?

Conclusion

Should you take the plunge?

How I made AB-testing work for our Server rendered React app and GTM+Optimize

The problem

Symptoms

Cause

Our solution

The nitty gritty (or, actual code and stuff)

Selecting the variant on the server

The experiment code

Rendering the experiment

The constructor

The componentDidMount

Integrating with GTM, GA, and Optimize

Page views

Experiment data

In conclusion

Using Husky git hooks with GitKraken

`V-model` on custom components

Why is it not `@latest`?