The All-Stimulus App
Understand how to build a full-featured Rails app fully powered by Stimulus and TypeScript. Learn to handle user interactions, dynamic seat selection, and server communication through ActionCable, while organizing code with Stimulus controllers and domain logic. This lesson helps you see how Stimulus compares with React in complexity and structure, and guides you through designing interactive components within Rails views without adding extra JavaScript frameworks.
We'll cover the following...
You may have noticed something about the two main examples in this course: they are slightly tuned to what we thought might be the strengths of each framework. The Stimulus page is, well, Stimulus-y. It has a lot of text markup, and the interaction is mostly deciding whether to show or hide things based on filters. The React page is more… reactive. There’s more text and just a little bit more of a state that depends on another state.
But what happens if you swap?
We thought it’d be interesting to close out the course by showing what the React page looks like in Stimulus and vice versa. We didn’t add any new tools to the app to do this.
To answer your possible first question, we don’t think there was a dramatic difference in how long one version or the other version took. We’ve been working with these samples for a long time, and the underlying logic mostly transferred. If forced to choose, converting the schedule page to React was probably longer; it’s certainly more verbose.
While it’s not exactly an apples-to-apples comparison, the React versions of both pages are about an extra one-third lines of code (roughly 525 to 400).
Some of this is TypeScript boilerplate. React encourages the creation of more domain objects, and, in conjunction with TypeScript, that just means more code devoted to defining types. So, the difference would likely be slightly less pronounced if you just wrote JavaScript.
Some of this is React ...