Open tacman opened 2 years ago
Thanks for filing this issue.
I've made the library compatible with Symfony6: Check out https://github.com/ph-fritsche/symfony-adr/releases/tag/v1.4.0
Thanks.
What do you think about a demo repo / tutorial? I'm new to ADR, it looks interesting, but I'm having a tough time wrapping my head around it.
On Mon, Jun 20, 2022 at 10:30 AM Philipp Fritsche @.***> wrote:
Thanks for filing this issue.
I've made the library compatible with Symfony6: Check out https://github.com/ph-fritsche/symfony-adr/releases/tag/v1.4.0
— Reply to this email directly, view it on GitHub https://github.com/ph-fritsche/symfony-adr/issues/1#issuecomment-1160519467, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEXIQI7DFHV6YEMXB5FRQLVQB6BVANCNFSM5ZGLGGMQ . You are receiving this because you authored the thread.Message ID: @.***>
Have a look at https://github.com/ph-fritsche/pitch-demo. Does this showcase the concept for you? Would you help improving the documentation so that this library might be useful to others?
Yes, thanks, that's helpful, to see it in action. I'm still struggling a bit, but I'll re-read the article after diving into the code more.
I'll add a README there and submit a PR, and open an issue there as to some of the dependencies. In particular, the demo uses phf/collection, how essential is it to use that?
Have you considered creating some makers? e.g. bin/console make:adr? I'm not sure how it would work (because I'm still learning how, why and when to use ADR), but perhaps it would help toward re-recreating a demo.
But having the demo is definitely helping to see where things happen
phf/collection
is just a utility to express someType[]
. It is not necessary to use it at all, just a convenient method to express a List of typed elements.
pitch/symfony-adr
provides the separation of Response and Action. Just like you define classes for entities that you store in the database, you should create entity classes for payload created at runtime, e.g. a paginated table page as response to a search endpoint. Then you add handlers to convert these entities into a response that is acceptable for the client. For a browser view this might be HTML and for a JS client library that might be JSON and for a spreadsheet export this might be XLSX.
pitch/form
allows you to remove the reoccurring form handling from controllers and just deal with the submitted and valid form there. If you use it with pitch/symfony-adr
, you can add handlers to convert the FormInterface
for GET and invalid POST requests into responses that are acceptable for the client.
Have you considered creating some makers? e.g. bin/console make:adr? I'm not sure how it would work (because I'm still learning how, why and when to use ADR), but perhaps it would help toward re-recreating a demo.
I've written these packages to reduce repeated code and thus make it easier for me to circle back to projects months/years later to apply changes.
I've made these open-source so that others who might find it useful can collaborate on this. This is issue#1, so no idea how many users for a maker would be out there. ^^
I'm working on a maker to replace Symfony's CRUD, it's heavily dependent on API-Platform and StimulusJS. I became intrigued by the idea of using invokable controllers, and this led me to ADR and your bundle. I'll keep reading what you've written and your code, quite interesting to see. Thanks again for putting it together and sharing it.
It'd be great to see this bundle in action.
In particular, what I'd like to see is a trivial application like this
And then refactor the controller to use your bundle and ADR.
Also, the above doesn't work, because the bundle is locked to Symfony 5.