Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generic wizards #6

Open
ju5t opened this issue May 8, 2021 · 5 comments
Open

Generic wizards #6

ju5t opened this issue May 8, 2021 · 5 comments
Assignees
Labels
question Further information is requested

Comments

@ju5t
Copy link

ju5t commented May 8, 2021

I am really looking forward to using this package! Thanks for making this open source!

I have a few questions, specifically about Livewire. From reading the docs, and a little bit of source diving, I think it will be difficult to support it. The package is pretty opinionated. The concept is great, but I would love to be able to use it generically.

This goes for standard controllers, too. We validate our data in controllers using form requests. It would be cool if we can make them part of a wizard. It would only have set and get data from the wizard, instead of a model for example. Most concepts can stay, a little bit more flexibility in the controller/routes would be very useful, I think. It allows us to stick to what we do, while using the power of your package to deal with all the difficulties of wizards.

Is this something you would consider in the future?

@ksassnowski
Copy link
Collaborator

Hi there!

I’m not super familiar with Liverwire so it’s hard for me to answer this at the moment. My understanding was that Livewire is more of a way to embed components into a page instead of replacing or changing the HTTP response cycle (like how Inertia.js does, for example). But it seems like that’s not how people are actually using it? I would have thought that it would be no problem to let Arcanist be the controller and take care of the view rendering (using the Blade renderer) and then embed a few Liverwire components inside the step views.

Can you give me a few concrete pointers as to what would need to change in Arcanist or what currently makes it difficult to use with Livewire?

I would love to also support Livewire in the future but there are a few architectural changes I want to make to the package first. So I can’t promise anything in the very near future. But maybe there are a few low-hanging fruit I could change before that so it’s at least usable in the meantime.

Appreciate your input!

@ksassnowski ksassnowski added the question Further information is requested label May 9, 2021
@ksassnowski ksassnowski self-assigned this May 9, 2021
@ju5t
Copy link
Author

ju5t commented May 9, 2021

My understanding was that Livewire is more of a way to embed components into a page instead of replacing or changing the HTTP response cycle (like how Inertia.js does, for example).

First off, not familiar with Inertia, so I don't know how to compare it :)

We use Livewire for our input forms and validation. An options is to render Livewire components into a page. We use full-page components where routes point to our components. The problem is the same though: a component would not know about or have access to the fields you specify in the wizard. Everything is constrained within the component. Same goes for validation.

Can you give me a few concrete pointers as to what would need to change in Arcanist or what currently makes it difficult to use with Livewire?

It's dealing with input fields, validation and data. In Livewire all available input fields are bound to public properties of that component's class. If we have an input field where a user can fill in their name, there has to be a public $name; set in the component, as without it, apart from returning errors, it wouldn't exist in the component.

Having access to fields and validation rules would help. It's not 100% DRY, because fields are specified twice. It might need a PR in Livewire to support external data somehow to improve that (it might exist already, not sure about that).

In the end I would like to stick to full-page components and have control over my own routes. This means some other methods in the wizard needs to accessible, if they aren't already (next step, previous step). I understand that might be a bridge to far at this stage :)

@ksassnowski
Copy link
Collaborator

It would be great if someone could provide a simple repository which showcases how you would use Livewire to deal with multi step forms (without Arcanist). I’m sure that there might be some way that I could abstract this enough to make this work with Livewire but I’m not quite sure what I would have to abstract in the first place.

@ju5t
Copy link
Author

ju5t commented May 18, 2021

@ksassnowski I'm not there yet with our application and I don't have enough spare time to build an example straight away unfortunately. Sorry if my previous reply was unclear, I really tried to make it as concise and simple as possible.

In essence, what I'd like is:

  • A way to define steps by specifying either routes or possibly even classes.
  • Getting the current, next and previous step.
  • A way manually to store and access data per step (in Arcanist's Field types, but without validation).
  • Control over routes so we can make user friendly routes, e.g. /register instead of wizard/registration/{wizardId}/{slug?}.

That's probably 'all'.

When we start building a wizard I will try to share an example with some more details.

@thoresuenert
Copy link
Contributor

Most concepts can stay, a little bit more flexibility in the controller/routes would be very useful, I think.

Today Arcanist registers fixed routes for each wizard, from my understanding only to support the option to define middleware for each wizard.

If we find an other way to support middleware registration and we can use dynamic routes for all wizards, we have the flexibility to overwrite specific wizard routes.

@ju5t another thing could be: don't use the arcanist route registration and roll your own.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants