Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stimulus.js 2.0

discourse.stimulusjs.org

Post reply on HN
Print view View original

111–120 of 140 posts

Re: Stimulus.js 2.0

#111

Post by [deleted] »

NetOpWibby wrote: post #92
sph wrote: post #40

Earlier quoted context omitted.

My killer unpoly features: * easy AJAX loading like turbolinks ( ) * easy AJAX modal ( ) * submit a form whenever any input changes ( ) * respects the way HTML is intended to be used, so the page still works even when JS is disabled

I’m currently dealing with a modal issue within Svelte (pretty sure it’s due to createDispatch) and the Discord moves too fast to get help. Gonna check this out in the AM. EDIT: Couldn't sleep so checked it out now. Looking through the issues, there are a couple that are apparently "fixed in 1.0" but it doesn't look like 1.0 is coming anytime soon. Shame.

[deleted]

Re: Stimulus.js 2.0

#112

Post by 1_player »

gampleman wrote: post #103
1337shadow wrote: post #46

Earlier quoted context omitted.

Shadow dom is optional for web components, web components are still useful without it, so I hardly see how that could be a reason for "failed piece of technology". Also, did you try with pure JS ? no lit ? I just removed StencilJS from my component to go pure-JS and it turns out I really prefer it that way, maybe it would suit you too to do WC without any additional JS lib ?

In the above stack LiveView doesn’t play that well with web components that render their own children, as it will remove those children when it rerenders. So you do kind of need shadow DOM.

Actually LV can play nice with them if you add the phx-ignore attribute on the component itself

Re: Stimulus.js 2.0

#113

Post by cultofmetatron »

benzible wrote: post #39
1_player wrote: post #35

Earlier quoted context omitted.

> "PETAL stack" of Phoenix, Elixir, Tailwind, Alpine.js, and LiveView Oh, finally a hipster stack after my own heart. My initial stack used Web Components instead of Alpine.js, but after one year trying to make it work (using lit-element) I'm battered, bruised and I declare Web Components a failed piece of technology [1]. Alpine is interesting, but not powerful enough for my use case, which is encapsulating common UI…

Have you checked out Surface [1]? In a recent interview [2] Chris McCord hinted at merging at least some of Surface into LiveView. [1] http://surface-demo.msaraiva.io [2] https://thinkingelixir.com/podcast-episodes/024-liveview-upl...

I love where surface is going but its not ready for general use yet. last I checked, it was pinned to an older fork of liveview.

Re: Stimulus.js 2.0

#114

Post by m-localhost »

midrus wrote: post #90
gerry_shaw wrote: post #36

Unpoly https://unpoly.com is also worth a look if you are interested in these things. It combines Turbolinks and Stimulus functionality in a very usable way.

Happy unpoly user here too. I think it is way better than stimulus, turbolinks, htmlx, alpine, etc. Just doesn't have as good marketing as those.

Unpoly is pretty good and complete. What I don't like is loading page specific JS/CSS via javascript. Turbolinks manages that for me and turbolink still executes inline JS.

Turbolinks falls short in providing a "framework" in how to use third party libraries - how to initialize them and how to tear them down. I finally glued together a mini-framework with hints from stack overflow, but Unpoly and their concept of compilers[1] is much more consistent.

[1] https://unpoly.com/up.compiler

Re: Stimulus.js 2.0

#115

Post by benzible »

cultofmetatron wrote: post #113
benzible wrote: post #39

Earlier quoted context omitted.

Have you checked out Surface [1]? In a recent interview [2] Chris McCord hinted at merging at least some of Surface into LiveView. [1] http://surface-demo.msaraiva.io [2] https://thinkingelixir.com/podcast-episodes/024-liveview-upl...

I love where surface is going but its not ready for general use yet. last I checked, it was pinned to an older fork of liveview.

Look again - the current Surface release is pinned to the current LiveView release, 0.15.

https://github.com/msaraiva/surface/blob/master/CHANGELOG.md

Re: Stimulus.js 2.0

#116

Post by cultofmetatron »

benzible wrote: post #115
cultofmetatron wrote: post #113

Earlier quoted context omitted.

I love where surface is going but its not ready for general use yet. last I checked, it was pinned to an older fork of liveview.

Look again - the current Surface release is pinned to the current LiveView release, 0.15. https://github.com/msaraiva/surface/blob/master/CHANGELOG.md

thanks for the heads up, gonna try integrating this today and see what happens

Re: Stimulus.js 2.0

#117

Post by catwind7 »

Existenceblinks wrote: post #102
catwind7 wrote: post #84

Earlier quoted context omitted.

Sure! 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 butt…

Do you think Github.com UI is complex? They are using a very similar approach to Stimulusjs: https://github.github.io/catalyst/ And it's working great?

I don't know enough about which parts of the site you're referring to to say for sure, but stimulus / stimulus-like approaches are perfectly fine for most display-only views even if they're fairly complex.

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.

Re: Stimulus.js 2.0

#118

Post by catwind7 »

andrei_says_ wrote: post #94
catwind7 wrote: post #84

Earlier quoted context omitted.

Sure! 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 butt…

Thank you for the detailed answer. I can definitely see you’ve crossed the line of adding subtle interactivity to the dom :) The behaviors you describe are intricate and contain interconnected components which are probably managed by something like vuex (or the react equivalent)

Yeah, I also want to emphasize (again) that none of this is a criticism of stimulus - the key words / phrases they used two years ago and continue to use are things like "modest" and "augmenting html". Our needs were very different then. I'm not complaining that my hand saw isn't doing the same amount of work as a chain saw.

Re: Stimulus.js 2.0

#119

Post by catwind7 »

porker wrote: post #91
catwind7 wrote: post #84

Earlier quoted context omitted.

Sure! 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 butt…

Awesome answer. I work a lot on business systems with complex forms and agree with everything you say. We are still feeling our way for a solution as we don't want to move to a SPA (swapping one set of costs for another) but have outgrown our current SSR + hand-rolled JS + jQuery + Bootstrap JS mess.

I still have reservations about moving too heavily towards an SPA - we still mostly have server-side rendered pages that render with react components so we don't have to deal with things like client side routing. It's also still important for us we render most of the page server-side for performance reasons, but I'm not too informed about the specific trade-offs there in load times if we did push more rendering to the client.

I feel like there's some opportunity in the space to create a truly re-usable form library that can hook into your backend and be themed / customized to suite the look and feel of your app. There's some companies already in that space though, so I might take some time to check out some existing solutions and see if there's some kind of needs gap. What's challenging about this problem though (as I'm sure you're also aware) is that there are a ton of variability in requirements when it comes to forms - it's something I wish were more standardized but at times it feels like one of those bikeshedding topics where everyone has an opinion on how inputs show be displayed, how errors are shown, etc.

Re: Stimulus.js 2.0

#120

Post by aaronbrethorst »

swanson wrote: post #27
mike1o1 wrote: post #3

Stimulus has a very small surface area, but I find it really enjoyable to use when combined with Turbolinks. My only complaint/comment is that some of the HTML that I need to generate ends up being littered with so many data attributes, especially when combining multiple Stimulus controllers/behaviors. Has anybody found a clean way around that in Rails templates?

I share some of the same issues, I have found that ERB templates work better than HAML for lots of data attributes. Basecamp seems to use liberal newlines / spacing when creating html tags (like one line per attribute) so that might help. Server-side "component partials" still don't have a great story, but view_component is one emerging option.

Same. I’ve been a happy user of Haml for about ten years, but I think that Tailwind and Stimulus will permanently force me back to ERB :(
Post reply on HN