Qqwy
Development on Phoenix LiveView is of course in full swing. However, here are a couple of features I currently miss and proposals to add them to Phoenix LiveView.
Mouse Events
Currently, LiveView supports phx-click which triggers whenever there is a JavaScript click event.
In multiple projects I have encountered cases with a large need for other types of interaction. Specifically, custom form elements frequently require things to happen on mousedown, when dragging, or when doubleclicking.
I propose that the following events are added to LiveView (whose behaviour is similar to phx-click in that the same extra information is sent, as well as the phx-value-*s that are set on that particular element):
phx-mousedownphx-mousemovephx-mouseupphx-dblclick
Supporting other click-like events
I believe above list covers the most common interactions. Of course, there exist many more mouse-related (as well as more general touch-related) events.
On top of above list of events, I therefore propose that it should be made easier to hook into the existing code that sends a phx-click-like event to the server.
Reason:
If someone were to create custom JavaScript for such an event right now, the would not only be re-inventing the logic that LiveView itself uses. The bigger issue is that their logic will not share the updates/changes to the code LiveView itself has, forever lagging behind with the implementation.
To be more precise, the following is very difficult (already right now) to accurately reproduce in a custom JS hook:
- The new event should include all
phx-value-*s using the same naming conventions/conversions as a normal (built-in) event. - The new event should include the same meta information with the request.
- The new event should adhere to supplied
phx-debounceandphx-throttlesettings. - The new event should trigger on the correctly specified
phx-target. - This list will grow and change with future features being added to LiveView.
Proposal
Some standardized way to add a new type of click-like event to a Phoenix LiveView instance would be a solution, such as adding a configuration field that accepts a list of event-names or alternatively an object of event name keys with callback function values, where the callback function is able to do things before an event is dispatched and can yield to the event dispatching logic at some point (either by using ES6 features or by e.g. just passing in the function that can do the work as argument to the callback function so it can call it whenever it likes).
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 10 of 13 Posts
Qqwy
By the way, this proposal is tangentially related to this issue.
Qqwy
@chrismccord, @josevalim, @snewcomer: feedback would be much appreciated!
chrismccord
LV master allows you to define a metadata callback to populate the payload however you’d like. You receive the JS event + DOM target
Qqwy
Thank you! This is indeed great to make
phx-clickandphx-keydownmore versatile.But does it enable other kinds of mouse events? (In my quick perusal of the Git diff of the Merge Request containing the change you mentioned I was not able to find information about that, but I might have missed something.)
josevalim
Adding new events will always be a compromise, as we want to avoid having an excessive amount of “data attributes”. It is probably best for now to implement those as hooks.
Your argument that using a hook won’t provide all features as Phoenix is true but note you don’t have to support all features, only the ones you need. Also, by using a hook, you can actually stay ahead and do things that LV doesn’t currently.
kartheek
LiveView is evolving similar to Java Server Faces. Java Server Faces is more component oriented specification of server side rendering of views. Oracle ADF Faces is JSF based framework which had extensive support for building rich client applications.
ADF Faces has 2 types of events server-side and client-side - client side events were meant to be handled on browser side and server side events which will be sent to server for handling on it on server side. Table - 6-1, 6-2, 6-3, 6-4 have different events generated by ADF Faces.
Leaving this here for reference and prior art.
Qqwy
Thank you for your response! What you say is true, but it was not enough to remove the gut feeling that something is missing. I took a few days to think about this matter in more depth and to formulate my thoughts. What it boils down to, is this:
It assumes that the person writing the JavaScript for the hook and the person using the hook will be the same. If a hook only partially supports the things that LiveView does, then it is difficult to reuse that hook or publish it in a library.
Essentially, the cognitive overhead for understanding and using something that is only able to partially integrate with LiveView is much higher. I think this is where my gut feeling against ‘ad-hoc hooks’ comes from.
Does that make sense?
samaaron
I came here hoping to find
phx-mouse-downas click events on mouse up (which appears to be the default) aren’t at all intuitive for my usecase.I guess I can look into doing this (although I have absolutely no idea at this stage so it’s back to google for me). If I manage to figure it out, I’ll come back and add a little example here so others don’t have to search as much
chrismccord
for mousedown a hook + pushEvent is your best bet
samaaron
Yep, that’s precisely what I’m trying my best to figure out how to do. My issue is that I have zero javascript background, so knowing how to work effectively (or pretty much at all) with hooks is currently a huge blindspot for me.
I’m sure I’ll get there eventually…
[Update] - I managed it. Thanks everyone for your help and support
Will post here later with a short description of what was necessary.