What's the reason for splitting views into Components and Pages in the admin hub?

[pixelpeter]

For example:

• route calls the component: GetCandy\Hub\Http\Livewire\Pages\Customers\CustomersIndex in /Pages
• render() calls the view: adminhub::livewire.pages.customers.index in /pages
• the view calls the component: hub.components.customers.index in /Components
• render() calls the view: adminhub::livewire.components.customers.index in /components which then finally has the template and renders the view.

Is this considered best practice?
I currently can't see the advantage of this approach as the result looks the same to me when I direclty call GetCandy\Hub\Http\Livewire\Components\Customers\CustomersIndex in routes from the /Components directory instead of the one from the Pages directory

[alecritson]

Hi @pixelpeter

Livewire auto-loads components based on the config setting in the main Laravel app. Being inside a package, we didn't want to try and mess around with it as it likely would have an impact on how Livewire works at the app level.

The issue was we can reference the component fine for the route, but as soon as you try and do any Livewire requests, it would throw a 404 as it can't auto-load the component since it doesn't live in the namespace.

The workaround was as you outlined above, we register the components manually (although we've discussed making our own auto-loader) and then in the page component we call the registered one. You're right in the fact that some components do look the same, but in the name of keeping things consistent, we opted to do all components like this.

[pixelpeter]

Thanks for this detailed response.
So I will also use this approach to avoid the mentioned issues.
Thanks 👍🏼