-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Simultaneous $wire method calls always return the value of the last call #3510
Simultaneous $wire method calls always return the value of the last call #3510
Conversation
@danharrin - good catch. This is a bug. Here's what's happening: The ProblemAfter an "action" (component method) is called, the returned value is captured and dealt with in the following line of code:
As you can see, the returned values are stored in a key/value pair where the key is the action name. Therefore, if the same action is called twice with different returns, the last executed one will overwrite the previous one and both will be used on the front-end. The SolutionI see two solution paths: A) Assign a unique identifier/signature to each action on the front-end before the request is fired, then change the key/value pair to use the action "signature" instead of the action name, that way information can be tracked properly. B) Preserve the current schema, but allow for arrays of return values in the order of execution - then, assuming the order is preserved throughout the lifecycle, the front-end can retrieve the proper return value. Which one to choose depends on how well the order of actions is preserved throughout the request/response. And also if it is preserved, do we want to depend on that order preservation. My gut tells me an action "signature" is the right way to go here, my only hesitancy is adding a new concept to the payloads and adding extra bytes to every single request/response - the latter is probably negligible, but it's always a consideration with Livewire. What are your thoughts? |
Thanks for the insight! I was discussing this with @joshhanley the other day and we settled on the signature approach too - didn't consider the performance implications but IMHO this is really not a massive problem. Would you like to implement the solution yourself or do you want me to have a go / pair with you? |
I'll have a go at this myself - also, this failing test was failing for the wrong reasons - I updated it. |
Thanks for bringing this up @danharrin. I went with the signature route and test is now passing. |
Awesome, thanks Caleb! |
Since this update I get the following error: |
Failing test for #3065.