-
Notifications
You must be signed in to change notification settings - Fork 117
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
Stubbing a Req.Request in a Phoenix.LiveView.assign_async #429
Comments
I suppose this generalizes to GenServers that call Req in init/1 or a handle_continue/2 from init, so the mention of LV is maybe not necessary |
Mox allows you to pass a function to parent = self()
Req.Test.allow(MyApp.Req, self(), fn ->
send(parent, {:allow, self()})
receive(do: (pid -> pid))
end)
{:ok, live, _html} = live(conn, ...)
assert_receive {:allow, pid}
send(pid, live.pid) This is a little clunky. It means that, if a function is passed, it needs to be run in its own process to prevent deadlocks, but perhaps a pattern like this could work? It could be wrapped in a helper to make it a bit more ergonomic. |
Another solution would use telemetry events to hook into the process |
Yeah speaking of telemetry events, we have this Broadway guide: https://hexdocs.pm/req/Req.Test.html#module-broadway I think it is fine when people do that in their own GenServers and Broadway pipelines which I’d considered intermediate level but this is too much for people using LV so we should definitely improve this. Since Ecto sandbox works in LV we should have infrastructure in place to make that happen. Or it does in LV but not in async assigns? In any case, yes, this is definitely a priority and any help is appreciated. |
Wait, this seems to work already? https://gist.github.com/wojtekmach/2ee023315dd6ea209d67b6d3ef8cd985 Could you modify the snippet to show the bug? |
Disclaimer: I will note that this is an "advanced" use case which may not be solvable, but I wanted to have a discussion first.
Hello @wojtekmach, thank you for your amazing library, I love Req!
This issue is to determine if there's a possible solution for testing a Req.Request inside of async LiveView assign. Imagine the following live view (btw I can totally appreciate that this might need a change in LiveView but I'll start here if thats ok)
The problem here is that in order to test this LiveView and stub out the call to
Req.get!
, there is a race condition, as the request to the LiveView will have already been made before you get thepid back that you can call
Req.Test.allow/3` against.e.g.
Of course, this could be solved with some sort of conditional that uses environment config, or a mocking library like
Mox
orMimic
.However, I'd like to imagine there could be another way to propagate ownership so that the
allow
could be called prior to theLiveView
creation. This may require changes toLiveView
, it might be impossible, or it might not be something you want to support.Thanks for the consideration and feel free to close if this is something you are not interested in supporting
The text was updated successfully, but these errors were encountered: