Best practices about complex forms

[adddz]

Hi @michael-rubel, thank you very much, this repository is amazing and that's what missing on the web when it comes to Livewire!

When building complex forms, do you think it's usually better to split single parts of the form into different nested Livewire components (especially when they have some logic built-in, for example, the ability to upload an image, etc.) or the whole state should be inside the main component that handles the form?

Also, it would be great if you could write some best practices to show a loading spinner/state BEFORE the Livewire component initializes the data on the page. I find myself doing this very often and I feel like it can be done more in a more clean way.

Thanks again!

[michael-rubel]

I'm glad it helped, that was the point of this repository! 🙂

Speaking about forms, I'd rather go with Blade components as nested ones. Because when you pass variables downstairs to Livewire components, it performs heavy mapping on data (speaking in the context of milliseconds of course). wire attributes will still work in Blade components if you use them in Livewire parent, so if you're reusing Blade forms inside or outside Livewire it wouldn't make any conflicts. In general, I only use Livewire when I need its features and I can't passthru it to the Blade components.

For a spinner, I'd go to check the defer loading feature. It should be easy: you put some spinner icon when the page loads, and then make it hidden using wire:init when the component renders. I didn't do it myself but it should work. Let me know how it's going and we'll probably add it as a best practice. 😉

[adddz]

I feel like someone should write an ebook on how to use Livewire in real world scenarios. It’s definitely missing! 😉

Thank you for your answer.

I like the idea of using Blade components but let me ask you this: a good thing when using nested Livewire components is that they are not re-rendered all the times when the parent refreshes, so you can re-render them only when needed. Wouldn’t this be more optimal so the requests are kept small? If you use Blade components, everything is re-rendered all the times.

For the spinner, this is what I’ve done so far but I do feel like there’s a best and cleaner way and maybe you can see something I don’t:

• In all my Livewire components I have a public property called $readyToLoad set to false.
• The Livewire component has wire:init=“load” that does database queries and initializes the data
• At the end of load, I set $readyToLoad to true which hides the spinner and shows the actual component.

As I said earlier, this feels a bit messy.
Thanks again!

[michael-rubel]

I'm always offloading the logic to the services. In the Blade component, the only need is readable methods (or computed properties) calling these services.

---

To access protected properties in Blade, you need to use $this->property.

[adddz]

@michael-rubel it would be great if you could share some best practices of how you offload the logic to the services. By the way, excited for Livewire V3, I think the lazy attribute on the component with the placeholder method is exactly what we need to set a loading state.

[michael-rubel]

@adddz yeah, Livewire v3 will be amazing and have exactly what you wanted. 😉
Services, it's a different, more generic topic, so not sure it's worth mentioning there. All I can mention is how I communicate with the services from Livewire components, but it can't be considered as a "Livewire good practice" but general practice.

[adddz]

@michael-rubel Exactly! I think many others would benefit from general best practices even if they are not specifically related to Livewire. 😉

[howdu]

Just chiming in to say I've defiently be keen to see this too.