-
-
Notifications
You must be signed in to change notification settings - Fork 356
Use the full power of Stimulus #5
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
Comments
Hi Guillaume! Thanks for your feedback and thanks a lot for your ideas! Answering your message: 1/ Using disconnect callback You are absolutely right: I added this in the READMEs of the packages but it's a very good idea to add it on the Chart component. If you wish to create a PR for https://github.com/symfony/ux/blob/main/src/Chartjs/Resources/assets/src/controller.js, that would be awesome 2/ Using data maps My reasoning behind not using the data API but native JS getAttribute calls is the following:
In opposition to these two drawbacks, I don't see a huge value into using the data APIs in package controllers as they don't store a complex state for the moment. So the balance of drawbacks vs advantages went to not using the data API for now, but I can change my opinion if I missed some arguments in favour of it! 3/ Inheritance My current reasoning regarding inheritance is based on the experience of Symfony as a framework, in which providing features using vertical inheritance has major drawbacks:
Generally speaking, I feel the inheritance debate is a bit like the Inheritance vs Composition debate, and my mind favours Composition in this situation. I may be missing something of course, feel free to point it to me if so! |
Oh and also! I think it would be awesome if your stimulus-components library would be compatible with Symfony UX, would you mind if I open a PR to see how it could work :) ? |
I think this has been discussed and addressed. Thanks for chimming in! |
* /Users/dunglas/workspace/hotwire-bundle: prepare merge in symfony/ux tweaking how the cloned form is used in the docs (symfony#12) updating stream media type to match changes in Turbo (symfony#11) ci: setup GitHub Actions (symfony#8) fix: regressions introduced in #5 (symfony#7) Relax minimum php version (#5) fix: various quality improvements (symfony#6) test: add UI tests (#4) ci: add PHPStan ci: add PHP-CS-Fixer refactor: broadcast template conventions and config refactor: decouple Broadcast from Twig and Mercure feat: initial implementation
…ued" changes (weaverryan, kbond) This PR was merged into the 2.x branch. Discussion ---------- [WIP] [Live] Make Ajax calls happen in serial, with "queued" changes | Q | A | ------------- | --- | Bug fix? | yes | New feature? | yes | Tickets | None | License | MIT Hi! Consider the following situation: A) Model update is made: Ajax call starts B) An action is triggered BEFORE the Ajax call from (A) finishes. Previously, we would start a 2nd Ajax call for (B) before the Ajax call from (A) finished... meaning two Ajax calls were happening at the same time. There are a few problems with this: (i) Ajax call (B) is missing any potential data changes from Ajax call (A) and (i) complexity of multiple things loading at once, and potentially finishing in a different order. This PR simplifies things, which matches Livewire's behavior anyways. Now, the action from (B) will WAIT until the Ajax call from (A) finishes and THEN start. In fact, while an Ajax call is being made, all changes (potentially multiple model updates or actions) will be "queued" and then all set at once on the next request. TODO: * [X] Update the backend: for POST requests, the "data" was moved under a `data` key in JSON. Previously the entire body was the "data". * [X] Update the backend: for POST/action requests, action "arguments" were moved from query parameters to an `args` key in the JSON. * [x] Frontend: add tests for the `batch` action Ajax calls * [x] Update the backend: a new fake `/batch` action needs to be added that can handle multiple actions at once * [ ] A new `updatedModels` is sent on the ajax requests. If the signature fails, use this to give a better error message about what readonly properties were just modified. (in fact, this is the only purpose of sending this new field to the backend at this time). * [X] ~~Pass a `includeUpdatedModels` value to the Stimulus controller ONLY when in `dev` mode.~~ For consistency, we will always pass the `updatedModels` in our Ajax requests, though this is intended to be "internal" and we won't use it other than to throw better errors. * [X] ~~(Optional) If the backend has an unexpected exception (i.e. 5xx or maybe some 4xx where we mark that this is a problem we should show the developer), then render the entire HTML exception page (in dev mode only) so the user can see the error.~~ Done in #467 Cheers! Commits ------- 4fbcebe cs fix and small tweaks a0c4d3f use `Request::toArray()` 13d7110 mildly reworking to follow the logic of what is happening more clearly (#5) b47ece1 [Live] add batch action controller 8b1e879 Refactoring towards single request & pending updates
# This is the 1st commit message: WIP heavy refactoring to Component Initial "hook" system used to reset model field after re-render Adding a 2nd hook to handle window unloaded reinit polling after re-render Adding Component proxy # This is the commit message #2: fixing some tests # This is the commit message #3: Refactoring loading to a hook # This is the commit message #4: fixing tests # This is the commit message #5: rearranging # This is the commit message #6: Refactoring polling to a separate class
# This is the 1st commit message: WIP heavy refactoring to Component Initial "hook" system used to reset model field after re-render Adding a 2nd hook to handle window unloaded reinit polling after re-render Adding Component proxy # This is the commit message symfony#2: fixing some tests # This is the commit message symfony#3: Refactoring loading to a hook # This is the commit message symfony#4: fixing tests # This is the commit message symfony#5: rearranging # This is the commit message symfony#6: Refactoring polling to a separate class
First thing first, I'm so happy to see this project! It's a huge deal for Stimulus and Symfony!! 👍
Under this title, I mean multiple things.
I think all controllers should use the disconnect callback to destroy instances. Like the Chart one.
If I dynamically remove the node from the DOM, the chart instance will remain loaded.
Stimulus has a pretty handy API to deal with data: https://stimulusjs.org/reference/data-maps
It's cool because it's name-spaced by default, so it "forces" developer to use it in a more generic way. And it has methods to access datas.
I see lots of
this.element.getAttribute('key')
but they are not using data-mapsAll controllers dispatch a custom event "extends" controllers in a some way.
I think it would be more consistent to allow developers to extends these controllers like here with instance variables and so on instead of using custom event. Because sometime, it's useful to override the behavior.
Thanks a lot for this project!
The text was updated successfully, but these errors were encountered: