208 karma · joined February 16, 2017
There are pages in our app where stimulus works great and the UI is fairly complex from a standpoint of the number of strictly user facing behavior (click this, show X, Y, and Z).
The complexity involved in handling form UI is just not very suitable for stimulus from my experience. That said, you can still do a lot in terms of following good programming practices to create something that looks and works great and is reasonably maintainable.
It ultimately comes down to your (and your teams) tolerance and business needs - there's no hard reason we need to stop using stimulus, we've just decided that there are parts of our app where we could make leaps in developer productivity by using something else.
One typical example is a component that collects (and displays) education history provided by the user. I'll list out just a few key UI behavior:
* A "read" view which represents a list of containers with titles that show each instance of a users answer (for example, if you provided 5 sets of answers, such as 5 universities you attended, we need to show those 5 in some sort of preview form on the page)
* A button that when clicked opens up a modal which contains multiple "steps" - each step is a small set of form inputs that range from simple ones like date to more complex ones involving search / autocomplete or file uploading.
* A button inside the modal that lets you navigate through the various steps / groups of form inputs.
* A "save" button inside the modal that persists your answers. This closes the modal and shows your set of answers as an instance in the list view (see the first bullet).
* In-line validation errors as the user is filling out each step of the modal
* Messages to notify the user that a modal needs to be opened and completed (Like if the user closed the modal before filling everything out, we want to let them know it's not fully completed).
Where some of the biggest complexity crop up:
* Form input data handling and general state management. As I mentioned, we can have upwards of maybe 20 controls in this component. At minimum, we need to write code to listen to input changes and make sure this new information is kept in sync with both internal component state and other parts of the UI. If you gave us a valid answer, we need to make sure to update the UI to show a checkmark (in the simple case). We also have controls that show or hide based on your answers to other form controls, so we'll need to handle inputs by potentially hiding or showing other inputs.
* Ok, so what if we need to write some UI updating code? Well, updating any part of the UI requires manual DOM manipulation. At minimum, this can be something simple like toggling visibility of an element by adding or removing a class. At worst, this involves appending html template strings (like if we need to show a list of errors on top of the modal) when the user attempts to save bad answers.
* Cross-component communication is difficult. Want to add a subcomponent? And it needs to communicate with the parent? For example, each step in our view is sort of a "sub form" and it needs to talk to the parent "modal" to keep global state - you'll need to roll some basic event handling code between the two.
* Testability. All these DOM changes - how do we test that our component is behaving? At the time we adopted stimulus, there wasn't a standard way of testing our stimulus controller so we've mostly leaned on (expensive) UI integration tests.
Some of this complexity is sort of inherent to forms - forms are complex UI components. There are hosts of libraries in other frameworks for dealing with form inputs alone (in order to cut down on the boilerplate you have to write). For example, formik in react helps cut down on a ton of boilerplate you have to write in order to wire the form control DOM state to react state.
Some of this complexity is also our own doing - we keep A LOT of state in the DOM. If a user blanks out an answer, we need to update the DOM with an additional form control whose value will get passed back to the backend to persist the change in the DB. Moving over to ReactJS won't help us here - this will require changes to our backend vs frontend API's.
However, having to handle the bulk of those DOM changes yourself requires a lot of code, is pretty error prone, and quite hard overall to maintain (as anyone who has rolled apps using vanilla javascript can attest to). StimulusJS doesn't offer many facilities for changing your UI in a declarative way.
Finally, cross-component communication is very common and while there is a number of ways to pass data back and form between stimulus controllers, there isn't really a nice way to do it outside of passing events. This is fine for simple cases, but error prone for our use cases. In reactjs, invoking callbacks that change parent state feels much more straightforward and has been easier to test.
Hope that helps
Not knocking on stimulusjs, but just be wary that it does not grow well with increasing client side complexity. You'll end up writing a lot of javascript boilerplate / DOM manipulation code / custom state management components. From my experience, it's a nice lightweight tool for when you:
1. Just need to add some light interactivity (toggling visibility of components, any basic view filtering) that do not involve a lot of logic 2. Don't need j.s unit tests (stimulus has not been the most testable tool - we lean mostly on integration tests).
I think it's a really underrated / underinvested skill in the industry (from my experience) with a lot of complexity. For example, there's so many levels of listening. It's one thing to understand what someone is saying but yet another to pick up on meta messages (facial expression / body language) that signal true thoughts / feelings.
I think a big part of _keeping_ that drive if you have it (or cultivating that drive if you don't) requires a sort of being able to experience delight / happiness from learning new things. Even the little things.
Like today, I learned a tiny shortcut in writing rails routes. Not a huge game changer obviously, but little things like that make me smile!
You can't be effective at your job if your manager sucks and you work with rude coworkers.
Thanks for taking the time to engage! I've also learned quite a bit reading through everyone's responses.
I think this confidence is really important and part of it seems to come from having solved lots of problems in the past / working through frustrating periods. That's why "write lots of programs" is still my favorite piece of advice because it's a lot like "show up to the gym" if you want to get stronger.
I think it's also difficult in practice because it feels good to master things in general. It's a nice feeling to know that you know a system inside and out, so detaching from that is going to be hard no matter what especially if you've invested quite a bit of your life into it
I think the difference for me is that the importance of communication for solo programming is a bit of a sliding scale depending on what your goals are. There aren't many exceptions when you work on a team. When I use the word importance, I'm tying it to a notion of necessity in relation to some goal. Team goals trump individual goals in organizations.
if you have no intention of making your code available for someone else to read / use / modify, the benefit for having readable code is really for yourself in six months and nobody else.
you also don't need to tell anyone what you're doing, so being able to clearly / succinctly explain what it is and why it's useful isn't a necessity. Does that make it an unimportant skill? No, it's just that the goals are different
I agree - so much of our time is spent coming up with working models of systems
I may be wrong here but my impression from this comment is that you _want_ to improve, have a sense of where you can improve, but you have not found an improvement plan that works for you.
I can relate to the frustration of seemingly not being able to move the needle for your skills. One thing that has helped me over the years is adopting more effective learning strategies.
I highly recommend the books "A Mind for Numbers" by barbara oakley and "5 elements of effective thinking" (don't remember the authors) for some ideas on how to deepen your knowledge (so that you don't just feel like you possess purely surface level knowledge).
That's very true. I think it's an easier sell when you have a relatively stable set of specifications (accounting software core logic) where the rate of change is low but the cost of regressions is high. But I think you can tackle the same problem space with good unit tests instead of enforcing a test-first mindset.
In situations where work is vague, spending more upfront time thinking about architecture is much more useful (design docs?) imo. Having a set of units for a crappy, entangled system is pretty costly.
If you've never tried TDD for a real project, I still highly recommend it for those reasons alone. It may not be your cup of tea and it may end up being extremely unproductive for you, but hey at least it'll give you some experience-backed opinions for this never-ending debate :)
Not to knock on using libraries or anything like that, but we've definitely felt the pain of putting tools / convenience ahead of architecture.
Rails has an incredibly large community but I think this statement would be equally true for any tool you're well versed in
if we detect life so near to us and _yet_ we still have yet to encounter life from another planet means there's likely still _some_ kind of filter. So I don't think the likelihood of no filter is high if we detect life