Elixir Blog Posts

In the second post in my series on Elixir macros, I introduce the concept of a “quoted expression”, and show how to create them using quote and unquote .

1 Like

I wrote up an experiment I did using metaprogramming to add guard clauses to the match operator.
Match Operator Guards

3 Likes

New post on the Dashbit blog:

Req API Client Testing – A guide through different testing approaches with Req-based API clients.

5 Likes

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.

2 Likes

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?

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."

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?

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.

Explore how Elixir’s Commanded library revolutionizes application development through CQRS and Event Sourcing

1 Like

My favorite GenServer pattern :slight_smile:

https://mattpo.pe/posts/erlang-delayed-send/

What if another client calls before the previous data is returned? You don’t want to clobber the from field blindly.

1 Like

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.

1 Like

A small tip on how to silence the noisy Phoenix.NotAcceptableError and Phoenix.CSRFProtection.InvalidCSRFTokenError exceptions in your Phoenix application by implementing the Plug.Exception protocol for them.

2 Likes

The focus of this article is to demonstrate various ways of registering a GenServer in Elixir so that the server can be discovered and communicated with by sending messages. Elixir runs on Erlang BEAM virtual machine and BEAM nodes can run on a single machine as well as in distributed mode as a cluster. In this article, we will explore various ways to register a GenServer both locally and globally using working code examples.