DEV Community: Sebastian Nitu

Using a Vanilla JavaScript module to handle CSS transition states

Sebastian Nitu — Tue, 01 Sep 2020 00:10:34 +0000

In a lot of my front-end work, I end up having to create open and close transitions for components. Things like modals, drawers, dropdowns, etc. After doing that a few times, I started to notice a pattern and wondered if I could turn that pattern into a reusable module instead of re-writing variations of that same logic. These were my core requirements:

The transitions should be handled by CSS, not JavaScript. That means if the transition duration for one component is different from another, the JS should just work in both cases.
There should be the ability to turn off transitions and just switch between the two final states.
Transitions should prevent spamming, meaning I don't want to trigger the "closing" transition if the component is currently "opening".
Return a promise so we have a way to write code that happens after a transition has finished.

Here's a working example of the code we'll be writing:

Notice: The example in this article is for an "open" and "close" state, but it really could be the transition between any two states. "Open" and "close" are just the two I use the most, even tho I'm aware the example transitions aren't actually "open" or "close" states.

Lets start with options

First, I want to create an options object where we can store our settings. We'll want to define our state classes here and whether or not transitioning is enabled:

const options = {
  stateOpened: "is-opened",
  stateOpening: "is-opening",
  stateClosed: "is-closed",
  stateClosing: "is-closing",
  transition: true
};

Create our transition module

Next, lets create a new file called transition.js and define an "open" function that returns a promise.

const openTransition = (el, settings) => {
  return new Promise((resolve) => {
    resolve(el);
  });
};

Right now, it's not doing much, we're just resolving the promise and returning our passed element. So lets put together our transition condition first.

const openTransition = (el, settings) => {
  return new Promise((resolve) => {
    if (settings.transition) {
      // Lets transition the element...
    } else {
      // Transition is disabled, just swap the state
    }
  });
};

For our disabled logic, that's pretty simple, we just need to remove our closed state and add our opened instead. Then we can resolve the promise.

el.classList.add(settings.stateClosed);
el.classList.remove(settings.stateOpened);
resolve(el);

Now, if transitions are enabled, we want to do the following:

Begin the transition from state a -> b by setting the transitioning class and listening for the transitionend event.
Once transitionend has been hit, we can then swap our transition class for our final state and resolve the promise.

el.classList.remove(settings.stateClosed);
el.classList.add(settings.stateOpening);
el.addEventListener('transitionend', function _f() {
  el.classList.add(settings.stateOpened);
  el.classList.remove(settings.stateOpening);
  resolve(el);
  this.removeEventListener('transitionend', _f);
});

The cool thing about this is we're only adding an event listener during transition. Once that transition has finished, we can remove it until another transition call is made.

Our final code for the openTransition now looks like this:

const openTransition = (el, settings) => {
  return new Promise((resolve) => {
    if (settings.transition) {
      el.classList.remove(settings.stateClosed);
      el.classList.add(settings.stateOpening);
      el.addEventListener('transitionend', function _f() {
        el.classList.add(settings.stateOpened);
        el.classList.remove(settings.stateOpening);
        resolve(el);
        this.removeEventListener('transitionend', _f);
      });
    } else {
      el.classList.add(settings.stateOpened);
      el.classList.remove(settings.stateClosed);
      resolve(el);
    }
  });
};

With that finished, we can put together the corollary closeTransition function pretty easily by simply moving around which classes are being added and removed, like so:

const closeTransition = (el, settings) => {
  return new Promise((resolve) => {
    if (settings.transition) {
      el.classList.add(settings.stateClosing);
      el.classList.remove(settings.stateOpened);
      el.addEventListener('transitionend', function _f() {
        el.classList.remove(settings.stateClosing);
        el.classList.add(settings.stateClosed);
        resolve(el);
        this.removeEventListener('transitionend', _f);
      });
    } else {
      el.classList.add(settings.stateClosed);
      el.classList.remove(settings.stateOpened);
      resolve(el);
    }
  });
};

To turn these two functions into modules, we'll just need to export them both, like this:

// transition.js
export const openTransition = (el, settings) => {
  // ...
};

export const closeTransition = (el, settings) => {
  // ...
};

Adding our markup and trigger logic

Lets start with a contrived example just to illustrate how flexible these transition functions are. Lets create an index.html file where we have a button and then some element we'll transition between two states.

<!-- index.html -->
<button class="button">Trigger</button>
<div class="box-track">
  <div class="box is-closed"></div>
</div>

It's important to note that we're adding our components default state directly, in this case is-closed. If you wanted the default state to be open, just add is-opened instead.

Now, lets create an index.js file where where we'll import our new transition module, define our options and get ready to work with our two elements.

// index.js
import {
  openTransition,
  closeTransition
} from "./transition";

const options = {
  stateOpened: "is-opened",
  stateOpening: "is-opening",
  stateClosed: "is-closed",
  stateClosing: "is-closing",
  transition: true
};

const el = document.querySelector(".box");
const btn = document.querySelector(".button");

Next, lets add a click even listener to our button. Notice that this is where we'll be checking if our component has finished transitioning. We don't do anything if our component isn't in a "final" state such as is-opened or is-closed.

btn.addEventListener("click", () => {
  if (el.classList.contains(options.stateClosed)) {
    // ...
  } else if (el.classList.contains(options.stateOpened)) {
    // ...
  }
});

Now all we have to do is use our imported transition module and open the component when it's closed, or close it when it's opened. We'll write this asynchronously to take advantage that we're returning a promise.

btn.addEventListener("click", async () => {
  if (el.classList.contains(options.stateClosed)) {
    await openTransition(el, options);
    // Do stuff after open transition has finished...
  } else if (el.classList.contains(options.stateOpened)) {
    await closeTransition(el, options);
    // Do stuff after close transition has finished...
  }
});

And that's it for our JavaScript! The final index.js should now look like this:

// index.js
import {
  openTransition,
  closeTransition
} from "@vrembem/core/src/js/transition";

const options = {
  stateOpened: "is-opened",
  stateOpening: "is-opening",
  stateClosed: "is-closed",
  stateClosing: "is-closing",
  transition: true
};

const el = document.querySelector(".box");
const btn = document.querySelector(".button");

btn.addEventListener("click", async () => {
  if (el.classList.contains(options.stateClosed)) {
    await openTransition(el, options);
  } else if (el.classList.contains(options.stateOpened)) {
    await closeTransition(el, options);
  }
});

Adding our CSS transitions

The last part of our example is adding the CSS transitions to our component. Here's the beauty in all of this, we can essentially write any transition with any transition duration and our JavaScript should handle it just fine.

For simplicity, we'll just be transitioning between a background color and transform properties so it's not a true "opened" and "closed" state but it shows what's possible using minimal styles. Here's our base styles:

.box-track {
  position: relative;
}

.box {
  position: absolute;
  width: 50%;
  height: 6em;
  border-radius: 8px;
}

Now, lets introduce our state styles. This will be the styles that our final states will have:

.box.is-opened,
.box.is-opening {
  background: salmon;
  transform: translateX(100%);
}

.box.is-closed,
.box.is-closing {
  background: forestgreen;
  transform: translateX(0);
}

Finally, lets add our transition styles only to our states that care about transitioning, is-opening and is-closing:

.box.is-opening,
.box.is-closing {
  transition-property: background, transform;
  transition-duration: 1s;
  transition-timing-function: ease-in-out;
}

Conclusion

Putting all these together, we now have a reusable transition module that can be used across multiple components. Our transitions themselves are handled completely by our CSS and we can add to our transitions module with different transition types as needed.

Here's a few resources along with two components that use the above transition module:

Link to CodeSandbox example: https://codesandbox.io/s/transition-module-example-pu1wm
Modal that uses transition module: https://vrembem.com/packages/modal/
Drawer that uses transition module: https://vrembem.com/packages/drawer/

Have any questions or suggestions for improving the code above? Drop a comment below and thanks for reading!

Why do bundlers import module fields but don't transpile by default?

Sebastian Nitu — Mon, 24 Aug 2020 21:34:09 +0000

By default bundlers resolve a packages import from the module field over the main in package.json (webpack and rollup, for example) which points to a projects ES6 module entry.
By default bundlers ignore transformations on anything from node_modules.

Aren't these two behaviors contradictory?

There are solutions to this:

Change the mainFields option to import main before module.
Change your exclude option to transpile specific package(s).
Use an es-check and only transpile packages that need it.

But yeah, this has always confused me. Am I missing something? Why do they do this?

My Favorite CSS Selector

Sebastian Nitu — Tue, 18 Aug 2020 00:03:18 +0000

During my time as a front-end developer, I've been adopting patterns that help me author CSS in a way that's easier to maintain, expand and not having to constantly override default styles.

sebnitu 🌹

@sebnitu

I can't stress this enough: DON'T put default margins on things. Trust me, it's going to bite you in the ass. If something needs margins, it should be handled by the parent component or via utilities. Margins assume a specific context you just can't predict.

01:21 AM - 21 Jul 2020

0 2

Margins are unique in CSS because they assume a specific context. For example, if I give every <p> element in my site a top and bottom margin of 1em, I'm going to need to reset those margins inside my components almost every time. Otherwise, I'll have to write my components in a way that assumes all <p> elements are going to have margins.

Components should only care about themselves, not their context. That job is for the parent component. So if I have a sidebar with a set of children widgets, the sidebars job is to add proper spacing between widgets, not the widgets to have default margins for when their context is a sidebar.

Being a good parent

The best CSS selector is all about being a good parent and not delegating the responsibility of the parent to the children. For that, we use this selector:

> * + * {
  // ...
}

This selector targets the adjacent siblings of all direct children of an element. Here's a CodePen example so you can understand which elements are being targeted as well as their specificity:

There are two main reasons why I love this selector:

It doesn't add to the elements specificity. A simple .class selector is equal in specificity weight to .parent > * + *. This is absolutely HUGE if you're using a low specificity CSS authoring pattern such as BEM.
It allows us to handle the spacing of our children without having to make the children worry about that stuff. Now THAT's being a good parent!

In the wild

There are two places I use this selector in my projects. The first is a generic .type component that handles the styles for a block of HTML elements such as a blog post. Usually this type of content is maintained inside a markdown file or a WYSIWYG editor, so you don't have control over the HTML output. But with these styles, you'd pretty much be good to go:

.type > * + * {
  margin-top: 2em;
}

I also have a spacing utility that I include in most of my projects. It's output is built using this Sass code:

$spacing-map: (
  "xs": 0.25em,
  "sm": 0.5em,
  "md": 1em,
  "lg": 1.5em,
  "xl": 2em
) !default;

.spacing > * + * {
  margin-top: map-get($spacing-map, "md") !important;
}

@each $key, $value in $spacing-map {
  .spacing-#{$key} > * + * {
    margin-top: $value !important;
  }
}

Which gives me a tool for adjusting the spacing between a components child elements without having to create a new modifier for every component that needs it.

Thanks for reading!

Has front-end development changed? What is a front-end developer suppose to know?

Sebastian Nitu — Sun, 05 Nov 2017 20:33:12 +0000

So I started in the field as a web designer and front-end developer. But all that has meant to me is that I design web based projects and then I code them into HTML, CSS and some simple JS. That's pretty much it. I know a bit about programming and I can make my way around most codebases for templating, theming or whatever. But it seems like the field of front-end development has changed.

So here's my question, has the job of a front-end developer expanded? Does it mean much more now than just being able to write HTML, CSS and JS? If so, would I still be considered a front-end dev or do I need to learn React to still be able to call myself a front-end dev?

Thanks!

Reusing Design Systems with Yarn and Gulp

Sebastian Nitu — Mon, 01 May 2017 04:51:23 +0000

Throughout my years of working with design systems, I've developed a different perspective on front-end development. I no longer view projects as their own enclosed ecosystems, but rather as the result of my growth within my field. My hope is that with every completed project I walk away with a refined skill set that I can carry on to the next. But what happens when I go back to maintain a project that I've "outgrown"? Often times it's simply not worth the time investment to keep an isolated design system updated.

In an ideal world, we should be able to let our projects grow along with us. Even if that's not perfectly realistic, I think it's valuable to develop a process that allows us to propagate our design systems across multiple projects as easily as possible. So as an attempt towards that goal, I've started using Sass framework packages as a place where my projects inherit their design systems. This allows me to focus on project specific styles while also giving me a hook to manage these systems across a wide range of projects while I grow as a developer. Here's how it works:

The important thing to note here is that anything explicitly defined in the project specific styles act as an override to our base design system. This allows us to update our base system without fear of losing any customization that our specific project requires.

I'm going to walk through the way I accomplish this using BaseWeb, Yarn and Gulp. BaseWeb is my personal front-end development framework, but this workflow can be used with any framework such as Bootstrap, Foundation or even a personal framework. As long as the project is published on NPM, you can use this method.

Lets install our framework using Yarn. If you're using your own personal framework, simply publish it to NPM and replace any reference to BaseWeb with your project's package name:

$ yarn add baseweb --dev

Next, we'll create our project specific SCSS directory (scss/) and a directory for storing our final CSS output (css/):

$ mkdir scss css

This part is specific to BaseWeb; we'll copy over a few files from the package. We'll only need three: baseweb.scss which contains all the import declarations, then _overrides.scss and _custom.scss partials---the former is where we override variables and the latter is a starter file for our project specific styles. Both of these are located in the custom directory so we'll just copy the whole thing. For brevity, lets also quickly define an environment variable with the path to the BaseWeb package's SCSS.

$ bw=node_modules/baseweb/src/scss/
$ cp -i $bw'baseweb.scss' scss
$ cp -R $bw'custom' scss

Note that the only real requirement here is a file to store our @import declarations. For more information on how BaseWeb overrides variable maps, check out the documentation here.

We can comment out or delete any imports we don't need for our specific project from baseweb.scss. The only required imports in BaseWeb are the settings and core files, but these don't actually output any styles when compiled. They simply provide variables and mixins that are used in other element or block components.

Next, we'll need to put together some build scripts to compile our SCSS into production ready CSS. Lets add gulp and gulp-sass as development dependencies and create gulpfile.js for writing our tasks:

$ yarn add gulp gulp-sass --dev
$ touch gulpfile.js

Next, lets open up gulpfile.js with your favorite text editor, in my case that's Atom. We'll be defining a few variables and initiate our CSS task for processing SCSS.

var
  // Modules
  gulp = require('gulp'),
  sass = require('gulp-sass'),

  // Directories
  dir = {
    src: 'scss/',
    dest: 'css/',
    // This part is important. We're saving the path to our framework package.
    bw: 'node_modules/baseweb/src/scss/'
  }
;

gulp.task('css', function() {
  // Our CSS task goes here...
});

One important thing to note is that we're storing the path to our framework package---we'll be using that in a pretty cool way next. So lets put together our css task.

gulp.task('css', function() {
  return gulp.src(dir.src + 'baseweb.scss')
    .pipe(sass({
      outputStyle: 'compressed',
      includePaths: [
        dir.src, // 1. Check our project specific files
        dir.bw   // 2. Check our framework package
      ]
    })
    .on('error', sass.logError))
    .pipe(gulp.dest(dir.dest));
});

The real magic happens in the options we're passing to gulp-sass which accepts the same arguments as node-sass. Specifically includePaths, where we include two paths; our project specific directory and the framework package. What this does is it will search in these two locations for a file that we call using @import. If a file can't be found in our project specific path, Sass will look for that file in the framework package. Let's give it a test run:

$ gulp css

We've just compiled our SCSS into a production ready CSS file: css/baseweb.css. Even though most of our imports aren't located in the project itself, those get inherited through our framework package. Now we can work on our project specific styles and not worry about our base design system getting out dated or diverge with custom edits. Since these are separated, the latest updates to BaseWeb can be leveraged by running:

$ yarn upgrade baseweb

That's it! For further reading on design systems, I highly recommend Brad Frost's book "Atomic Design". If you have any suggestions or tips on this method, let me know! I'd also love to know how you maintain your projects and the solutions you've come up with. You can find the source to this example in this repository.

Hi, I'm Sebastian Nitu

Sebastian Nitu — Thu, 13 Apr 2017 19:13:24 +0000

I have been coding since 2008. I live in Washington where I work remotely for Avelient. I'm a UI designer and front-end developer.

You can find me on Twitter as @sebnitu and on GitHub.

Nice to meet you.