DEV Community: Ilya Radchenko

6 Tips For Transitioning To Ember CSS Modules

Ilya Radchenko — Fri, 10 Jan 2020 18:44:32 +0000

A few tips as you transition your SASS, LESS, PostCSS or plain CSS to using CSS Modules, and specifically for Ember (not sure what the differences are).

Use `local-class` Instead of `class`

This is Ember only, and is just a requirement at the moment. This attribute is used to convert the generated classes and insert them into your template.If you pierce component styles (see next section), you should leave your old class until you migrate away.

Add Classes to Components Used In Templates

CSS Modules don't let you style inside of components you use in your template, so you need to add a class.

<User local-class="user" />

Is required to target that component, otherwise you'd have to use :global, which should be used sparingly. If you need to expose deeper classes, then it's recommended to add arguments, like @roleClass and using the helper:

<User local-class="user" @roleClass={{local-class "role"}} />

Use `:global` Sparingly

It's alright to use :global if you do lots of component piercing and are migrating, but I recommend setting up stylelint and using the selector-pseudo-class-no-unknown rule, so you can catch missed globals when you go to refactor:

module.exports = {
  rules: {
    "selector-pseudo-class-no-unknown": [
      true,
      {
        ignorePseudoClasses: ["global"],
      },
    ],
  },
};

Wrap IDs in :global

IDs get transformed, not sure why, so use :global(#my-id) {}.

Refactor Away From Component CSS Parent Selector

The following is not supported to target the default element (in classic components, or the route namespace):

& {
  display: flex;
}

You need to wrap that template in a new class, like .page. This is especially true if you are transitioning to Glimmer components.

Don't Use Element Selectors In The Top-Level

You must include selectors like h1, a, p inside of a class in your style file, otherwise those will apply to your whole app.This is because the style file doesn't get its own namespace, only the classes (and IDs) inside the file are renamed.

Works Well With TailwindCSS

In the past I've used Tailwind and have wondered about the case where you need to define your own components, it seemed like back to the same old CSS with it's normal limitations. CSS Modules enter stage right, and it's a great combination of using a subset of CSS and for the last 10% you dip into CSS Modules which live right next to your components.

I've also been working on SubsetCSS as a side project and it helps with keeping the same subset of CSS that Tailwind uses, so you can keep consistent styles across your whole codebase.

Repost of https://ilyaradchenko.com/6-tips-for-transitioning-to-ember-css-modules

When Components Aren't Enough

Ilya Radchenko — Wed, 08 Jan 2020 04:20:48 +0000

Sometimes components are too high-level, and you need to get at a specific DOM element, either for scrollTo or focus, in these situations Ember provides a lower-level primitive called an element-modifier. To get started with element modifiers you can check out existing modifiers at EmberObserver or create your own using the ember-modifier library.

Some Examples

<form {{autofocus}}>
  <input />
</form>

Which will focus the first non-disabled input that it finds (from ember-autofocus-modifier).

<div {{scroll-to}}>
  Some content here
</div>

Which will scroll to the element once it's in the DOM, and is super easy to implement:

// /app/modifiers/scroll-to.js
import { modifier } from "ember-modifier";

export default modifier((element) => {
  element.scrollIntoView({
    behavior: "smooth",
  });
});

There is also the ref modifier from ember-ref-modifier which gives you access to the element:

<button {{ref this "button"}} data-name="foo">
  Click me baby, one more time!
</button>

{{this.button.dataset.name}} >> "foo"

Along with {{on-click-outside}} from ember-click-outside.

<div {{on-click-outside @close}}>
  Your HTML...
</div>

Why Are Element Modifiers Useful?

Mainly because you can do things like:

{{#if this.isEditorVisible}}
  <div
    class="wysiwig-editor"
    {{did-insert this.setupEditor}}
    {{will-destroy this.teardownEditor}}
  >
  </div>
{{/if}}

Which handles the setup and teardown of the element, so if isEditorVisible turns false the editor initialized on our element will be properly cleaned up. This is important because the new Glimmer Components allow multiple top-level elements without any kind of fragment syntax.

Note: I'm using ember-render-modifiers in the above example. But you could create a modifier to encapsulate both the setup and teardown so reusability is easier.

One Reason Why You Should Be Using URLs

Ilya Radchenko — Fri, 03 Jan 2020 03:40:30 +0000

One of the reasons that Ember.js is so powerful of a framework is because of its Router, and ultimately its bet on the web and the fact that the URL is important. With Ember's router, the URL becomes a nested state-machine for your app, which is one of the reasons you should be using URLs in your app whenever you can. Let me explain a bit.

I'm just learning about state-machines, and from what I can tell one of the basics is that in the most simplest of state-machines, you represent a single state that can happen at one time. So for example, fetching or errored for an AJAX request, you cannot be in both states. Ember.js gives you these two for free in the router, the loading and errored routes (or substates as the guides call them).

The way that Ember has routes and UI setup promotes these exclusive states in the UI, because nested routes map to nested UI. So if you have a wizard UI for an onboarding kind of experience, you can model each step of that onboarding flow as a nested route:

this.route('onboarding', function () {
  // 'index' is predefined and is step 0
  this.route('step1');
  this.route('step2');
  this.route('step3');
  // 'loading' is predefined
  // 'errored' is predefined
});

As you can see, if you visit onboarding you will land on the index route, which can be step 0 or can redirect you to the correct step. This is the initial state of our onboarding state-machine. If the index route loads something, it will transition to loading before rendering. So you can only be in one of the substates of the onboarding route.

You can now transition from index to another sibling route using transitionTo on the router service or on routes (transitionToRoute in a controller). Something like this.router.transitionTo('onboarding.step1'). Once again loading and maybe errored will be entered during/after the model loading phase. Using this structure to define nested UI, since the child routes are nested in whatever UI is defined in the onboarding template, allows you to define exclusive states and prevents subtle bugs that might creep up if you decided to handle these steps using {{#if (eq this.step 'step1')}} syntax, especially if you have multiple if statements for the same state for different pieces of UI, it makes it hard to reason about and allows your app to be in unknown states you didn't intent.

So in closing, the URL is important, because it drives nested UI in a state-machine fashion which keeps your app easier to understand, read, and prevents bugs in many cases.

If you want to read more about routing, check out my post about Using Nested Routes In Ember.

Ember's Nested Routes and URLs Explored

Ilya Radchenko — Thu, 05 Dec 2019 22:14:07 +0000

Ember's router is powerful and a bit unique, in that it has a nested structure for the routes which build up the URL a user would see in the browser.Given it's power, it is easy to be unsure about how to structure your routes, especially in scenarios where you have parent-child UI patterns or CRUD like resources.

One of the patterns that I've learned is not using extra nesting when want to build out a multi-part URL structure, like /users/1234, which seems like it should be nested, but generally a single level is enough. I'd structure it like this:

this.route('user', { path: '/users/:userId' });

This puts your user "view" route at the app/pods/user directory (my examples will use PODS, since they are sane for routes).The following is generally not the way I'd write my router map, even though it creates the same URL pattern.

this.route('users', function () {
this.route('user', { path: ':userId' });
});

Unless you are showing the list of users at the same time as the selected user, which I think is a rare pattern, this is probably not the way your route should work.The reason I wouldn't do this is because it adds unnecessary mental overhead between the list and a selected item from the list.With my preferred pattern, if I wanted a list route, it would be a sibling to the resources.

this.route('users');
this.route('user', { path: '/users/:userId' });

And the folder structure is sane as well:

app
pods
  users
  user

Since the two usually don't share any common UI, the common UI will probably be one route up or at the application route.Well that's it! Let me know if this is how you do it or if you completely disagree.