-
Notifications
You must be signed in to change notification settings - Fork 894
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
@myself can work by accident #895
Comments
Tangentially, a follow on proposal: send_update should raise if the component doesn't existCurrently the behaviour is that nothing happens. This makes it difficult to sort out where the problem is. Is the problem that I'm not using the right component id? Or is the issue that I'm not doing the right thing in |
For the first issue, maybe we can make For the second issue, there is #739. Note we should warn and not raise, as race conditions could make it so the component no longer is on the page. For example, imagine you do an async request that should "reply" to the component, but someone closes the component on the UI. |
Good point about #739. A warning or even a debug level thing would all work fine for the purpose of debugging in development, so cool! With respect to the main issue, if I see a CID (presumably Component ID) I guess I still don't have a strong sense that this is something internal vs something that the parent has. Can you elaborate on why |
@benwilson512 the ID is something you control and it can be anything. The CID is completely internal to LV and is used to communicate between client/server. |
OK great, makes sense. |
…able Example of the race condition mentioned, from phoenixframework#895 (comment): > Note we should warn and not raise, as race conditions could make it so the component no longer is on the page. > For example, imagine you do an async request that should "reply" to the component, but someone closes the component on the UI. Closes phoenixframework#739. Refs phoenixframework#957.
…able Example of the race condition mentioned, from phoenixframework#895 (comment): > Note we should warn and not raise, as race conditions could make it so the component no longer is on the page. > For example, imagine you do an async request that should "reply" to the component, but someone closes the component on the UI. Closes phoenixframework#739. Refs phoenixframework#957.
…able Example of the race condition mentioned, from phoenixframework#895 (comment): > Note we should warn and not raise, as race conditions could make it so the component no longer is on the page. > For example, imagine you do an async request that should "reply" to the component, but someone closes the component on the UI. Closes phoenixframework#739. Refs phoenixframework#957.
…able Example of the race condition mentioned, from #895 (comment): > Note we should warn and not raise, as race conditions could make it so the component no longer is on the page. > For example, imagine you do an async request that should "reply" to the component, but someone closes the component on the UI. Closes #739. Refs #957.
Harder to get it mixed up with things like `assigns.id`. Closes phoenixframework#895.
Harder to get it mixed up with things like `assigns.id`. Closes phoenixframework#895.
Hey folks,
Recently when attempting to use
send_update
on 0.12.1 I created something that worked by accident, and then later broke, which was very confusing.The short version is that I was doing this inside a live component:
And then in the parent doing:
This shouldn't work.
@myself
is documented to be the "internal unique reference" to the component. However, it did work because at the end of the day@myself
is merely an integer counting up from 0. There were 2 components on the page, so it had a value of1
. Also, I was editing the form component for product id 1, so voila, the value worked.I should have been doing
{:result, socket.assigns.id, result}
.I propose that
@myself
should be namespaced in some way to make it very difficult for it to accidentally collide with a specific external component id.The text was updated successfully, but these errors were encountered: