[Question] Resource Methods to Separate Components?

[ghost]

Hey Kevin,

I'm really digging this package so far ... I don't know if you saw my comment on YouTube, but I'm currently testing on Octane and it runs fantastically so far. The fact that your service provider doesn't bind anything to the container certainly helps.

I'm assuming that the way you have components built, I'll need to create a separate component for each resourceful controller method.

ie: given I have model for Product in a products table:

App\Components\Livewire\Products\Index.php
App\Components\Livewire\Products\Show.php
App\Components\Livewire\Products\Edit.php
App\Components\Livewire\Products\Store.php
App\Components\Livewire\Products\Update.php
App\Components\Livewire\Products\Destroy.php
App\Components\Livewire\Products\Restore.php

I very much like this approach anyway as I prefer an ADR style framework where my action would be responsible for just receiving a request, then passing that request to the domain layer to be handled, and returning a payload to a responder.

Will you be accepting pull requests? I feel like just from this initial look there are some improvements that can be made, interfacing, publishing stubs, adding a dedicated config file so that config settings in the provider can be configured by the user and pulled into the commands.

Honestly it's really surprising how much this package accomplishes with very little code.

It's very impressive my friend.

Let me know if I can collaborate with you on this.

Great job!

[bastinald]

Hey yes that's how you create the resource components.

I'm working on auth and basic crud right now to add to the package.

I just need to make sure it's minimal. I will be accepting PR's for sure.

Thanks for your feedback.

[ghost]

Cool. Any hint on which package you'll be using?

I think I'm going to focus this weekend on creating a Jetstream package using your package.

It would be great to see if this can be ported right into Jetstream and get all those features but still be using just Malzahar components.

I've started doc blocking, adding type declarations on the properties and methods and that will be my first pull request.

Probably later tonight or tomorrow.

[bastinald]

I'll be making the auth from scratch so that I can keep it super minimal.

You should be able to use Jetstream or Breeze with this, but then there will be a mix of Malzahar and non-Malzahar stuff.

When I add auth it will just be a command and then it will add your auth components with actual Malzahar components.

[ghost]

hmmmm .... I wonder if maybe it WOULD be better to leave it out altogether and let the user decide how to implement authentication for themselves?

[bastinald]

I think its good to let people decide, but it would be good for this package to have the option for it.

which is why I will make it into commands. so if you want auth scaffolding, just do malz:auth. crud will be malz:crud {class} etc.

the install command will only create a basic welcome page.

and I need to make the stubs publishable for sure.

[ghost]

Yeah for sure on the stubs ... I do a lot of interfacing, and I'll want to use Snowflake ID's for all my models so I'll need a stub for that.

I don't know what other people are doing in that regard but but auto-incrementing IDs are a huge anti-pattern imho.

[ghost]

Probably the config file too, I'd prefer my livewire fullpage components to live in Pages as opposed to Livewire.

[bastinald]

Probably the config file too, I'd prefer my livewire fullpage components to live in Pages as opposed to Livewire.

The only problem is livewire will only accept 1 path for knowing where it's components live.

So I'd recommend just adding "pages" and "partials" folders to your "livewire" folder, that way you can keep your pages and partial components separate.