Symfony UX: Turbo

We're working at max speed to deliver this course, just be a bit more patience :)

Cheers!

Hey DjTapke,

Good catch! It's still top-secret for now, (so don't tell anyone! :) ), but we're going to start working on it in late April / early May. It's very rough estimation, so things may change anytime, but I don't think we will have it earlier than in May :) I would like to suggest you to subscribe to this course on the course intro page: https://symfonycasts.com/sc... - we will notify you when we will start releasing it.

P.S. We're very excited about this Turbo feature as well in SymfonyCasts! ;)

Cheers!

the sound of clicking here and there? :p

Hey Tomato,

Double-check the scripts section of your package.json file, you should have something like this

    "scripts": {
        "dev-server": "encore dev-server",
        "dev": "encore dev",
        "watch": "encore dev --watch",
        "build": "encore production --progress"
    }

then, try running the command this way yarn watch

I hope it helps. Cheers!

Yo Julien Quintiao!

That's a really great question. The short answer is: use those libraries... but disable turbo for those sections :). For Turbo to work (as you know), your JavaScript needs to be written "correctly". For something like EasyAdmin, there is a lot of JavaScript that you don't have control over. And so, there's nothing you can do. But I don't think it's a huge deal: use Turbo where you can, and skip it where you can't.

I'd love to see EasyAdmin refactor their JavaScript to use Stimulus. Their JavaScript isn't "incorrect" currently, but it would be awesome to see it done in Stimulus. But, it *would* be a big job.

Cheers!

Hey Dave B.!

Hmm, that's an interesting question! My first instinct was to say "just return the turbo-frame WITH the final content (instead of a lazy turbo-frame with src="") from the turbo-stream". However, I think see why you're doing it this way: this update will go to MANY users... and then each user's browser will then make the "lazy turbo frame" Ajax request to get THEIR personal data. Is that right? If so, it's a pretty clever way to update different content for many different users at the same time :).

Anyways, back to your problem. I also can't think of a "slick" way to fix this, I don't believe there is any mechanism inside of turbo to allow this. So, you would need to do something tricky. For example, you could do something like:

<turbo-stream action="before" target="{{ my_frame_id }}">
    <template>
        <turbo-frame id="tmp_frame_update" src="{{ path_to_special_controller }}"></turbo-frame>
    </template>
</turbo-stream>

I've changed the action to before. Instead of replacing the frame, I am adding a NEW frame right before it, that points to some OTHER controller (not the controller that returns the "{{ my_frame_id }}" content. Anyways, in that controller, you would return (not dispatch to Mercure, just return a Turbo stream response, I believe that would work... and not cause a frame error, but we'll see) another TurboStream that looks something like:

<turbo-stream action="update" target="{{ my_frame_id }}">
    <template>
        <turbo-frame id="{{ my_frame_id }}">
            THE REAL CONTENT HERE
        </turbo-frame>
    </template>
</turbo-stream>
<turbo-stream action="remove" target="tmp_frame_update"></turbo-stream>

Does that makes sense? It's kinda wacky... and I'm not entirely user that returning the TurboStream from the turbo frame Ajax call will be allowed... but we'll see. Another, similar idea, would be to do this exact same thing, except that instead of adding a turbo-frame id="tmp_frame_update" from the original turbo-stream, you could add a div element with a stimulus_controller() on it. That controller would then make the ajax call to the endpoint which would return the second turbo stream. You could then take that response and process it through the Turbo stream system (we show how to do that here https://symfonycasts.com/screencast/turbo/manual-stream).

Let me know if any of this helps or makes sense!

Cheers!

Hi Ryan

Thanks. Yes I wanted to use new Update() or Entity Broadcast to render user specific views.

Returning the turbo frame with the src to get this content works well e.g.

// _list.stream.html.twig
<turbo-stream action="update" target="{{ turbo_frame_id }}">
    <template>
        <turbo-frame
            id="{{ turbo_frame_id }}"
            src="{{ path('_app_product_crud_list_page', {
                stream: true,
                template: 'product_admin/crud/_list_content.html.twig'
            }) }}"
        >
            Loading...
            </div>
        </turbo-frame>
    </template>
</turbo-stream>

However a side effect was that it caused the Browsers Window to scroll up because the Users turbo-frame content momentarily gets replaced with the Loading html which takes up less height than the view content.

Original Temp Solution:

I first just approximated the size of the current turbo frame and in my '_list.stream.html.twig' replaced the loading html with a fixed height div e.g.

// _list.stream.html.twig
<turbo-stream action="update" target="{{ turbo_frame_id }}">
    <template>
        <turbo-frame
           .....
        >
            <div style="height: 1296px;">
            </div>
        </turbo-frame>
    </template>
</turbo-stream>

New Solution (seems to work so far!) :

Using the turbo-helper file add another event listener, watch for the before-stream-render response and replace the 'Loading' html with the current html showing in the view :

const TurboHelper = class {
  constructor() {

    ...otherListeners

    document.addEventListener('turbo:before-stream-render', (e) => {
      const frame = e.target.getElementsByTagName( 'template' )[0].content.children[0]
      frame.innerHTML = document.getElementById(frame.id).innerHTML
    });
  }

This seems to work and means I can use Entity Broadcast and new Update() to update User specific views without the page jumping around.

Im sure there is a cleaner way to write this btw.

Cheers

BTW to keep normal streams working as they should you need to add a check in the new event listener e.g.

document.addEventListener('turbo:before-stream-render', (e) => {
      const frame = e.target.getElementsByTagName( 'template' )[0].content.children[0]
      if(frame.tagName.toLowerCase() === 'turbo-frame' && frame.hasAttribute('src')) {
        frame.innerHTML = document.getElementById(frame.id).innerHTML
      }
    });

Hey Dave B.!

That's an awesome solution! I wasn't thinking about event listeners at all - I love this - well done, and thanks for sharing.

Cheers!

Hey Ruslan!

That's a pretty fair question :). My choice would be a multi-page app with Twig, but with Turbo and Stimulus immediately so that you can get the "single page app" feel. However, if what you're building is *quite* dynamic (it's more of an "app" on the web than a "web site"), you could make a strong argument for Vue or React. React is used by more people, but, Vue is quite popular and loved by its user base.

If you have any other questions or doubts, let me know :). On SymfonyCasts, we use Stimulus (and are in the process of adding Turbo). We also use React few a few super dynamic "widgets" on our site - like the coding challenges that are on some tutorials.

Cheers!

Thank you!

Yo Nick F.!

That's an excellent question :). It basically makes your site navigate more quickly & gives it more of a "single page app" feel. At first, you are probably wondering (as I did) something like:

> How? If Turbo changes clicks/submits to Ajax calls... but those requests STILL return the same full HTML page, how is that "faster"?

The answer (or at least the biggest reason, from my research) is that your JavaScript & CSS do not need to be re-parsed. Consider the "flow" for the 2 situations:

1) Traditional full page refresh:

A) the page is "downloaded"
B) all of your JavaScript is parsed & executed
C) all of your CSS is parsed
... then this fully repeats on every click. Your JavaScript and CSS may be cached (and that helps!) but they are always re-parsed.

2) Turbo-powered Ajax (imagine that they "first" page was already loaded, which includes the steps above and now you click a link)

A) the page is "downloaded" (same as above)
B) The HTML is put onto the page

That's it. Instead of your JavaScript being reparsed and reloaded on every navigation, it becomes a, sort of, "persistent" engine: it's parsed just once, then it just runs forever.

This, apparently, makes a big difference - because your site *does* feel a *lot* faster (there may also be some psychological effect to not seeing your browser "loading", but I'm just guessing).

If you have any other questions, let me know :).

Cheers!

I know! We're working at max speed to release this tutorial, please wait just a bit more

Hey Michael S.!

Absolutely! I was very sad to see the 2 maintainers leave :/. That being said, the community is huge, the projects using Stimulus & Turbo are huge - so we'll find a path forward. The technology is just too good not to :).

Edit: For others reading this, the loss of the 2 maintainers was not for any reasons related to the technology itself - but rather due to some ugliness inside of the company Basecamp.

Cheers!

Great! Really looking forward to this course! :)

Hey Axel!

We'll cover that :). Well, specifically Turbo and Mercure - there is absolutely a built-in feature for having a section of your site subscribe for updates and have them added automatically. It's pretty sweet.

Cheers!