Conversation
|
Let’s take this change all the way. No need to start by explaining |
|
Good call. Made some revisions in af233fe |
|
Much better! Probably need to revisit the title and intro, too: “Locate” now seems to describe the implementation rather than the concept. And we aren’t really “referencing” elements “by name” anymore, either. I would prefer to describe it more along the lines of linking targets to controller properties. |
|
I’m happy with chapter 2 of the handbook now. The last thing we should do is update the installation guide to mention the necessary Babel static properties plugin. |
|
It turns out that the Babel plugin for class properties is either going to work great or not work at all with our implementation. 👍Add the transform-class-properties plugin to your {
"plugins": ["transform-class-properties"]
}And classes with static properties like: class A {
static targets = […]
}Are compiled to: var A = function() {}
A.targets = […]👎Use the plugin's {
"plugins": ["transform-class-properties", { "spec": true }]
}And the same class compiles to: var A = function() {}
Object.defineProperty(A, "targets", { value: […] })Thus bypassing our setter: In Babel 7, this is going to be the default behavior unless you use the |
|
Thinking out loud...is it possible to get target properties without specifying them explicitly inside the controller? // src/controllers/hello_controller.js
import { Controller } from "stimulus"
export default class extends Controller {
//static targets = [ "name" ] without this line
greet() {
const element = this.nameTarget
const name = element.value
console.log(`Hello, ${name}!`)
}
} |
To avoid the potential pitfalls with Babel outlined in #61 (comment)
|
Possible solution to the Babel situation: c8e7696 |
e3fc4df to
88bfde8
Compare
To avoid the potential pitfalls with Babel outlined in hotwired/stimulus#61 (comment)
Define a controller's target names and Stimulus automatically creates properties for accessing them: