Flashy - A small library to extend LV's flash notifications

Lovely stuff. Would give this a spin on first chance I get.

This looks amazing, I’ll try to incorporate it into my next project for sure, if they are customizable enough in animation direction!

awesome stuff. I imaging these notifications (including the default flash) could be trigger on any page say when I am looking at a list but I have another important list I want to monitor that is not on the current page?

I didn’t make it customizable in that regard.

TBH I think the library can be more flexible in some regards like this one, for example, the code that do the transitions are in this file: flashy/lib/flashy/helpers.ex at master · sezaru/flashy · GitHub

We could make it like a behavior so you can replace it with something else, but I didn’t do it yet since I was not sure what are people requirements and use cases.

I’m not sure if I got the question right, but you should expect similar behavior to Phoenix flash since it uses it behind the scenes. As long as you have access to the page socket, you can add notifications to it and also to another page if you redirect.

Just to give some more context, what I mean as using flash behind the scenes is because that the built-in flash architecture from phoenix working like a key, value map.

Normally, with the flash_group component, you will send the kind of flash (:info, :error , etc) as the key and flash_group will show that. That’s why you can’t stack multiple :info flashs at the same time, because they will have the same key and its value will just be replaced.

What flashy does is two things, the first it use something else as the key, to be more specific I use a string like this as the key:

    key =
      :erlang.unique_integer([:positive, :monotonic])
      |> to_string()
      |> then(&"flashy-#{&1}")

    LiveView.put_flash(socket, key, notification)

That guarantees that each notification is unique and will not conflict one with another when showing them in the screen.

The other thing is that flashy uses a notification struct as the value, not a message. You can put whatever data you want inside that struct, but the only requirement is that you implement the Flashy.Protocol for it. That protocol will tell Flashy which component/live component to render.

Definitely the right call—better to not introduce the wrong abstraction early on until you have more use-cases.

For context, I maintain two LiveView PWAs and so to look good on mobile devices, my notifications tend to be banners that animate down from the top of the viewport; full-width on mobile and fixed-width on larger devices.

Those are nice, clean Phoenix.LiveView.JS structs that should be easy to let be more configurable! If I were tasked to make it more extensible, I’d probably start with allowing per-notification animations similar to other options, ex a @notification.options.show_animation, with fallbacks to your existing implementation.

I imagine after letting that cook for a while, some patterns for re-use would emerge out of realworld codebases—perhaps a callback module, or extra options to use Flashy.Normal, or project-wide config :flashy, :animations-type stuff!

Hey everyone,

I just pushed a new version of Flashy 0.2.0.

The main features of this version are:

• Fixed a bug that would not show notifications in the correct order;
• Added support to fully customize the components CSS and transitions.

@christhekeele I think this version will have all the customization you probably need.

I added a new section to the README explaining step-by-step how to customize the notifications to make them show in the left side as an example, you can find it here:
https://github.com/sezaru/flashy#customizing-css

I also added a branch called left_side_notifications to the flashy_example repo with these customization in case someone want to just see it in action.

Fantastic package! Been wanting this for a while! Just one question, perhaps I made a mistake, but it doesn’t seem to work at all on dead views. For example if we have a redirect due to “require_authenticated_user” plug and we add a message it crashes even if it redirects to a LiveView page. Is this expected behaviour or do I miss something?

Oh, I never tested deadviews, do you have a small code example that triggers the problem for me to try it by any chance?

love it mucho , thanks for your effort