30 Days with LAST Stack

Hey OldCoder,

Hm, that's weird behavior, please double-check what exactly you listen to to open the site search modal. Is that internal-input-suggested a pseudo-element? Could you share an example how you use that? Fairly speaking I don't know that internal-input-suggested, but quick googling of it shows that it may cause some issues. I suppose it's only Chrome browser feature? If so, probably that just has a bug with it. Otherwise, try to use it in a different browser, e.g. Firefox. The same behaviour?

I hope that helps!

Cheers!

Hey Tac,

So yeah, login/registeration form is just a regular form so you can handle it in the way we handle forms here. Basically, I bet LiveComponents will do the trick well here. The ApiPlatform might be an overkill for this IMO, but if you're already using that in your project - you can give it a try, though I personally didn't do that before.

About PWA - hm, not sure here, I personally don't have experience in that. So probably a lot of possible edge cases to solve, maybe it's better to watch into more specific tools like VueJS to implement truly SPA, etc.

I hope that helps!

Cheers!

Hey again @escobarcampos!

What a great course as always! I am actually applying the things I've learned here to my current project. Feels good to say good bye to encore!

Woo! Best possible situation!

I am a bit confused on when to use LiveComponents vs TwigComponents. I think I understand the difference... input vs no input? I guess I will need more experience to be able to decide on which to use case by case.

You need a LiveComponent if you need your TwigComponent to reload via Ajax as the user interacts with it. That's a pretty good rule of thumb. But, of course, you can also handle a lot of user interaction just with Stimulus & Turbo. So even if I created a TwigComponent (because maybe I want something to be reusable, or provide its own variables), if I need some interactivity (like submitting a form via Ajax), I might just use Turbo & Stimulus for that. But you can also use LiveComponents, and those are especially useful if the user interaction gets more and more complex.

Btw... do you know of any nice bundle that would make developing simple subscription webapps simpler? (eg. subsription plans, payment methods, orders, returns, recurrent billing, etc.). I found Shapecode but is 4 years old

I don't :/. I hope we can release something some day. I'd recommend checking out Paddle or Lemonsqueezy in general as your payment processor. They can handle a lot of the heavy lifting for you.

Cheers!

Hey @Kilian-K

I'm glad to know you find the tutorial useful. To change when to submit the form, you need to override the getDataModelValue() method from the trait Symfony\UX\LiveComponent\ComponentWithFormTrait

About EasyAdmin, I've not heard that they're planning to integrate LiveComponents but I'd imagine they eventually will. You may want to ask that question in their GitHub repository or perhaps in the Symfony Slack channel

Cheers!

Thank you for the answers MolloKhan, managed to make the validation on debounce happen with your tip! I am guessing the same about EasyAdmin, I guess it will just take a little bit of time!

Have a nice day!

Hey Damien,

It might depend on PhpStorm version. But the Symfony plugin activated and correctly configured (we use a paid version of it in the screencast btw) should do the trick with it. Other plugins - are mostly visual like "Atom Material Icons" and "Rainbow Brackets". Also, Ryan has GitHub's Copilot and Stimulus plugins :)

Cheers!

Hey @Steven!

This is a very good question / thing to notice :). And I think you understand the situation perfectly.

So yes, the real answer is "remove your full build system - you don't need it!". But if there is some tool that you want to use and it's built in Node, absolutely, go for it :). Your setup will still be 95% simpler than it was before. I say a lot about "removing node" because you don't "need" it. And this is such a big change, I'm trying to be clear a about this possibility. The real situation is more nuanced. Start with no-build, Then intelligently opt into tools if you want them. I think many apps may still have no node, but some might, and that's cool :).

Cheers!

Hey Fabrice,

In theory, it should be possible, you should just enable it for those pages in the way we show in our Turbo tutorial: https://symfonycasts.com/screencast/turbo . Though if you watched that course - sometimes Turbo may have some edge cases, that you would need to handle. What I mean is that I haven't done that myself yet, so can't say for sure, but you can easily try it out if you're interested in it and see if it works for you, but be ready to fix some edge cases.

Cheers!

Okay thank you!

Hey @Fabrice!

We'll talk a bit in this tutorial about how Turbo is great, but how you may not be able to enable Turbo Drive immediately in a legacy application. But, Turbo is 2 other pieces (Frames & Drive) and those are much easier to enable even in those situations.

About EasyAdmin, I get this question from time-to-time. I think that EasyAdmin itself will need to update how its JavaScript is organized a bit to allow for Turbo to be used. I would LOVE to see this happen and even help with it. As you'll see in this tutorial, we could do some really nice things like modals, etc easily in EasyAdmin if it embraced Turbo.

Cheers!

Hey! Imagine if we could do this in EasyAdmin, it would be incredible! Looking forward to seeing if this happens, and what possibilities it may offer!

I've opened an issue about it - https://github.com/EasyCorp/EasyAdminBundle/issues/6051 - we'll see :)

Oooh! Nice idea :)

Hey Ruslan,

Thank you for your feedback! What exactly testing are you talking about? The bundles we're using in this course are tested and have tests, you can see it in its repos. Or do you want to see the testing topic covered by this tutorial? Could you give us more context please?

Cheers!

I saw it and it's greate.
I woud like to highlite what 'Testing' is important part in each project, and will be good to see best practice for it.

Thank you.

Hey Ruslan,

I see what you mean. Unfortunately, I'm not sure testing will be covered with this tutorial, that's a completely different topic that requires its own tutorial. There are a lot of testing tools in JS that may help you with it, but mostly you can test it even with Behat/Panther - those tools help you to test UI in a real browser that executes JS, so you literally can open a JS popup, press buttons, send AJAX requests, wait for responses, etc. We have a useful blog post here: https://symfonycasts.com/blog/behat-panther . Also, we have a separate tutorial about Behat testing: https://symfonycasts.com/screencast/behat

I hope that helps!

Cheers!

I WILL spend some time near the end of this tutorial on testing - I have at least 1 day scheduled for it :). I don't know how far we'll get into it (I haven't written this part), but I want to make something real-world & usable.

Cheers!

Testing is why I prefer to separate backend and frontend. It simplifies both backend development (only APIs in Symfony, no Twig, no JS) and frontend development (JS testing in pure-js repository).

I've seen enough legacy Symfony projects with everything combined: Twig, JS, jQuery, Selenium driver, JS-enabled tests. In my experience, for big projects that grow over several years and need maintenance and upgrading, it's better to separate.

Hey @SRP!

I think this is totally fair! However, as a counterpoint, I wouldn't immediately choose the complexity of separating the frontend and backend simply so that my tests are cleaner and faster. Even in that case, I'm going to have end-to-end tests that verify the full user experience.

In the end, choose whichever you're most comfortable & happiest with. This tutorial is about proving that you can choose the Twig path and still build an incredible UI.

Cheers!

Hey @loevgaard ,

Thank you for your interest in SymfonyCasts tutorials! Right now, we're actively working on it :) According to our roadmap: https://symfonycasts.com/courses?status=upcoming&sort=popular#all - it should be the next tutorial that we will start releasing, so it will happen shortly after we finish releasing the "PHPUnit Integration Testing" course.

Cheers!

Thanks :)

dialog is my plan right now, yup! But we'll see once I get to coding that part :)

Oh my God! Did I read it correctly? Are you going to implement DataTable? It's awesome !

😀

I wonder how it will be used (in combination with Live Component??)

You CAN do it with this - especially once we merge https://github.com/symfony/ux/pull/1230 - but I'm planning to do it entirely with Turbo frames

Can’t wait to see this training, it’s going to be great!

Me too!

Hey Nick!

In general, the idea is to try to stop using Stimulus for simple things that could be done via Live Components... because it's like you're just "reinventing the wheel", you send (in theory) more time to implement the same that already implemented in Live Components, you flood your JS code with more files (Stimulus controllers), etc. So, Live components clearly have some benefits in some cases, you only need to know more about live components, how they work, and what they can do for you. So, in short, you can leave Stimulus for more complex unique cases that cannot be done with Live Components (when they are not enough to implement it).

AssetMapper is also a cool thing, and it helps you to avoid using NodeJS to build your assets, that's why it's cooler than Webpack Encore. For most of websites, Assets Mapper would be enough, and you can switch to it from the Webpack Encore (though it will require some work). In case you really work with Node in your app, then yeah, better to stick to Webpack Encore then. I would recommend you to watch the course about it: https://symfonycasts.com/screencast/asset-mapper - it will be much clearer for you if you need Webpack Encore, or if you can simplify and speed up your building assets process a lot with Asset Mapper :)

P.S. Some super secret info - we use Webpack Encore on SymfonyCasts, but we're planning to switch to AssetMapper instead (because it's just awesome), and we do have a lot of JS assets, Stimulus controllers, etc. behind the scene :)

Cheers!