New post on the Dashbit blog:
Req API Client Testing – A guide through different testing approaches with Req-based API clients.
wojtekmach
Hex Core Team
marcin
Hi,
I bumped on this article LiveView is best with Svelte
It has an interesting story on problems with Live View, and what they came up with: They use Svelte components to wrap live view hook objects for easier JS interop.
I thought maybe you’ll find it interesting.
pjode
In the article they mention a specific scenario and admit that they’re unsure if they just don’t have the mental model right to solve it the “LiveView” way and that’s why it was felt difficult to do. It involved the consecutive selects. Does anyone have thoughts on what the LiveView way would look like?
Pal
on the linked HN, from the creator of LiveSvelte:
"That’s true. And another downside is that once you’re in the Svelte environment you can’t use your Phoenix components inside those Svelte components.
I’ve thought about adding a library of default Svelte components which mirror the core components you get from Phoenix out of the box. But then again you lose forms and changesets etc, it’s just annoying.
Where I see LiveSvelte fit is where you really need a lot of complex client side state. Sprinkle it in, but keep using phoenix components as your default, even with hooks."
cmo
I would try rendering all the second selects individually and controlling the visibility of them with the first, or setting the options of the second with a hook, using "phx-update=ignore". Haven’t tried it though.
I thought their point that rewriting liveviews as live components is a lot of work was a bit odd. How often is one doing that that it’s an issue?
arcanemachine
Elixir + Phoenix: How to Raise Custom HTTP Error Responses in Your REST API
This blog post shows how, by adding a few lines of code, you can return a custom HTTP error response (with status code and custom message/payload) in your Elixir + Phoenix REST API, at any time in the request-response lifecycle.
karolina.curiosum
Explore how Elixir’s Commanded library revolutionizes application development through CQRS and Event Sourcing
mpope
derek-zhou
What if another client calls before the previous data is returned? You don’t want to clobber the from field blindly.
mpope
Good question. I have used this in two scenarios. The first is a gen_server (B) that backed a port which a single process (A) pulled data from. A would call B which would then buffer an unknown amount of data from the port then rely back to A. So only one process knew that process B existed.
The second was a single process that would pull data from a network source. It had a queue of gen_servers which had call’d it for data, which it would reply to once it received a full chunk of data from the network. Once a waiter was finished with processing the data it would add itsself back to the queue by issuing a call and block for a reply. In this case the waiters didn’t step on each other’s toes.