What’s planned for Stimulus 1.1

1

Hey everybody. I wanted to share what we have planned for the next release of Stimulus, version 1.1, so folks know where we’re headed in the near future.

Please keep in mind that none of this is set in stone and we don’t have a specific timeline at the moment. :slight_smile:

Support for abstract CSS class names. It’s very common for a Stimulus controller to add, remove, or toggle CSS class names on its elements. However, hard-coding those class names in your controller makes it more difficult to reuse. We’ll add a data-class attribute so you can easily map your app- or component-specific CSS classes to abstract names in a controller.

Warning messages for common gotchas. We want to go out of our way to help people write idiomatic Stimulus code, so we’ll add an opt-out warning system that lets you know when you’re using the wrong casing convention or when you reference an unknown identifier.

An integrated test runner. We have a lovely solution for testing Stimulus controllers in our @stimulus/test package, but it’s currently only usable if you’re willing to read the source and set up your own harness. We want to bundle a basic test runner that’s configured for you so there’s no obstacle to writing tests.

An appendix to the Stimulus Handbook with full documentation for naming conventions and descriptor syntax. This information is currently spread out across several chapters in the Handbook. There is also at least one feature that is currently not documented because there was no place for it to go.

Full API documentation provided by TypeDoc. We’ll publish it on the web site, and it will also be available in your favorite editor via our TypeScript .d.ts files.

A public @stimulus/polyfills package for easy IE 11+ support.

20 Likes
2

Good stuff. Could you expand briefly about abstract CSS class names? Maybe a short example?

Also, is there any plan to bring some sort of “syntactic sugar” for dealing with conditional rendering? I’ve been spoiled by Vue’s v-if and v-show.

3

The appendix sounds excellent! The docs that are there are really good but an all-in-one-place overview would be super useful.

1 Like
4

Also with the ability to render erb tags in the js file :hugs:

5

Are you using Rails with asset pipeline or webpack?

With asset pipeline you can already do this hello_controller.js.erb will preprocess and any erb tags will work as expected. Including access to helpers. I have not needed to do this recently with webpack though.

1 Like
6

NO!? I shall try this now! Thanks!!!

Edit

Just tried, not working @pelted. I am using Webpacker.

Edit

Nevermind. Got it working here: https://github.com/rails/webpacker#erb

7

That would be lovely, especially an example of the preferred convention for multiword naming might avoid some initial confusion. :slight_smile:

2 Likes
8

Full API documentation

This would be awesome! Is there a way to generate API documentation for current version? (sorry not familiar with pre-compilers)

1 Like
9

I would love to be able to append to the targets declaration array when extending a controller. For example, I have a base Form controller. If I need form-specific conditional logic, I have to redeclare all lof the base Form controllers targets in order to add additional targets for the child class. Not a big deal, but it would be nice.

10

That actually works already! Target definitions are additive so parent target properties are automatically inherited.

// base_controller.js
import { Controller } from "stimulus"

export default class extends Controller {
  static targets = [ "alpha", "beta" ]
}

// child_controller.js
import BaseController from "./base_controller"

export default class extends BaseController {
  static targets = [ "gamma" ]

  connect() {
    console.log(this.alphaTarget, this.betaTarget, this.gammaTarget) // 👍
  }
}
2 Likes
11

Hi. I know you specificly say “we don’t have a specific timeline at the moment”… but it’s been 3 months. Just wondering if there’s a timeline for 1.1 anytime soon?

Also, just saw this awesome PR: https://github.com/turbolinks/turbolinks/pull/390 – wondering if/when that’ll be merged as well. That fixes a lot of timing issues we’re having to work around.

1 Like
12

We hope to release beta versions of both Stimulus and Turbolinks soon. Still working out all the kinks: https://twitter.com/javan/status/1002673705158356993 :upside_down_face:

2 Likes
14

Hey Javan,

Just checking in to see how its going? Any updates for the community?

15

:tada::tada::tada::tada:

1.1 beta is out

time to yarn add stimulus@beta

5 Likes
16

Hi!

Do you know if there is also the new test runner?

17

Update!

Stimulus 1.1 is just around the corner. Not everything from the original list made the cut, unfortunately.

  • Support for abstract CSS class names
  • Warning messages for common gotchas
  • An integrated test runner
  • Full API documentation provided by TypeDoc
  • An appendix to the Stimulus Handbook
  • A public @stimulus/polyfills package for easy IE 11+ support

The features that didn’t make it are still on the table, and we’ve already made progress on some of them.

A beta release of 1.1 is available now and has no breaking changes. It’s unlikely that anything will change before the final v1.1. We’ve been running the beta in production at Basecamp for several weeks along with Turbolinks 5.2 (released this week).

Here’s a copy of the v1.1.0-beta.1 release notes for convenience:

  • NEW: Ordered actions (#149)
  • NEW: @stimulus/polyfills package for legacy browser support (#134, #147, #170)
  • CHANGED: Applications now start when the DOM is interactive (#131)
  • CHANGED: Unminified UMD module for easier debugging (#151)
  • FIXED: Stimulus now accounts for missing mutation notifications from nodes removed by innerHTML assignment in IE 11 (#133) and, in rare cases, when annotating elements synchronously after removing them from an observed tree (#161)
  • INTERNAL: Upgraded to TypeScript 2.8.1 and Lerna 3.0.0-rc.0
  • INTERNAL: New build system (#155)
6 Likes