Page refreshes with morphing in Turbo 8
Vložit
- čas přidán 26. 11. 2023
- This a demo showing how page refreshes with morphing work, and how they compare to stream actions. This is new feature coming with Turbo 8.
Learn more:
The Github repository with the demo code:
github.com/basecamp/turbo-8-m...
Companion blog post:
dev.37signals.com/page-refres...
Presentation from Rails World:
• Jorge Manrubia - Makin...
A happier happy path in Turbo with morphing:
dev.37signals.com/a-happier-h...
Did I just see 13 years of JS adventurism coalesce into a few lines of code?
Rails is so back.
What up dude
The pain of imperative DOM updates as were shown in the stream actions example is exactly why I started replacing my Rails front-ends with React back in 2015 or so. It's SO easy to introduce bugs when you as a developer are responsible for remembering every single thing that needs to change on every single action. Turbo stream actions look like a more elegant way of doing it vs. handrolled jQuery code back in 2015 but the essential problem is the same. If Turbo Morphing is as good as it looks then writing full-stack Rails applications is going to become VERY compelling again.
It blew my mind at Rails World, and it's blowing my mind again!
Working with Rails and Turbo is such a pleasure!
Thanks a lot to all the contributors!!
just want to thank you that your tutorial help me much to learn turbo
@@whyimustusemyrealname3801 I'm glad it helped!
Simply elegant and effective. Rails and Turbo are the best!!! Thanks to the contributors
As someone that's coming from the FE JavaScript framework world and exploring Rails for the first time, this looks amazing! This video might have single-handedly convinced me that this is a viable alternative.
WOW Just WOW! This makes more sense to me than hotwire / turbo stream and the rest of rails recent frontend tooling
Thanks for putting this demo out together. I really dig the addition of morphing!
One thing you didn't cover is that now with morphing we can also easily add CSS animations to elements. It was tricky before as the elements were being replaced in the DOM... but now they are being morphed (same elements), so the CSS animations will kick in! So cool!
Jorge, thank you very much for starting the video showing the turbo stream action with the update.turbo_stream.erb; that pain of having to update 3 different sections of the screen is very, very common, and I've always wondered if there was an easier way. Good to know that there wasn't, and now there will be!
So AMAZING!!!! I love it
Ok, second comment after finishing the whole video: this is a monumentous achievement for Rails. I'm impressed that with a single line in the model two different views will be updated with different partials each. This is groundbreaking stuff.
Thank you senhor Jorge.. Great tutorial.. Ruby on Rails is amazing and it is great to see how it is evolving..
Wow this is awesome! Thanks to everyone involved !
Unbelievable! Congratulation guys, this is simply amazing 🎉
Love it!! One point of feedback: the documentation doesn't (clearly) mention the approach you are taking in the video, which I think is a shame and missed opportunity.
This is so awesome Jorge. As someone who found out about Rails after learning SPAs (Angular) first, this seems just so incredibly productive. I already played around with turbo refreshes locally and found it amazing in the usecase of a table with many elements and the option to create and edit elements of that table within a dialog.
The only thing where I still needed to use a turbo stream was when the edit dialog (inside a turbo frame loaded on "edit" click) was submitted and produced form errors.
Thank you!
10:30 here's where he starts the Turbo 8 version, much simplified and to the point. Great stuff.
Wow turbo 8 is gonna be awesome.
Pretty amazing, also seems kind of correct and natural. Like you can imagine at some point in the future, browsers only updating the difference between response and current page, but keeping to HTTP/Websocket conventions like this. (sure there would be edge cases, but you know what I mean)
Oh my! This is huuuuuuuge! 🤩
Thanks for the video. Very interesting updates await in turbo 8.
How will turbo 8 broadcast the view partial for @item to allow only the author to edit/delete this @item?
Is there a way to scope those broadcast_refreshes to an account/tenant?
Керемет окылык! Енди терен демалып жайбыракат код жазсак болады🎉
Incredible demo.
Looks promising and I can remove lot of code. Great work! Challenge would be to migrate one model/page at a time without breaking things 😄
can't believe how it's easy!
funny at 5:45 how he says 'we need to do more things here' and i understand 'we need to do morphing here' and think to myself, i assumed we would talk about morphing, but this is kind of a harsh transition :D
It doesn't scale, they are going to say
This is fantastic, but I'm struggling with how to handle validation errors in the form? If I render :new on validation error then the whole page breaks
[4:10] How realistic is to have a client that doesn't support turbo? Is keeping the HTML format necessary?
if the client disables javascript or is on slow network (loading turbo for the first time in the head), there is no turbo yet, so the update action will be a plain old html form submission without turbo. except if you consider these use cases to be irrelevant, the idea is to support the web platform default and built a progressive improvement on top
@@1klap I am not sure if there are many clients disabling JavaScript those days.
Hey Jorge, thanks for putting this up. I've just noticed the the github repository is just an empty rails app. Could you add the code you worked on in the video. Would be super helpful.
Hey the code is in branches in the repo 🙂
@@jmanrubia Thanks Jorge, I just noticed that after I posted the question 😅
great work Jorge, thanks a lot. However i was not able to work it out in rails 7.1.2, and with turbo-rails (2.0.0.pre.beta.2)
and head loaded correctly.
i could not find the reason. any idea about what i miss?
5 days of debugging. still not working. Is there a must to follow rails conventions for crud operations to work with this?
My controllers have complex logic, multiple +10 @ variables returning on the index method , none follows @records, @record like convention. I am rendering them specificaly. might that be a reason?
Sounds almost too good to be true. Wonder where it will hit its limits.
I would love to try turbo v8.0.0-beta1 but I can't install it. Is there some resource someone could give that will help me give it a try? thank you very much!!
Edit: I installed the turbo rails gem 2.0.0, this enables turbo 8 I suppose? Please correct me if I'm wrong, thanks! 🤗
Great video Jorge! It seems my last comment didn't submit (apologies if you're seeing this twice), but how would you trigger an update for a collection like the code below? E.g. if you were to click "Delete this project" at 22:45, how could you broadcast or refresh the total projects count?
You have projects:
That would actually work, because deleting a project would broadcast the signal with the code shown in the demo. In the more general sense, there are two alternatives: (1) The way shown in the video: configure the association to touch its container, which will get updated when a child gets deleted. (2) Make the child broadcasts page refreshes (those will trigger on deletions too).
This is great! I am curious why did you call this "morphing"?
It's the term the industry uses for transforming one dom tree into another (check: morphdom, idiomorph).
I hope all of these great "under the hood" functionality are well documented so we don't need to read any source code to be able to "discover them". This has been a constant pain point on every single "cool new feature".
Hasn't even shipped yet and he's already whining.