RooSoft
Navigate to new page, sending some rather large info
Could it be possible to use a <.link> in a LiveView page, and include data that has to make it to the next page?
Thing is, the current page could be selecting stuff that’s too large to fit into an URL… I’d like the next page to get that info, maybe via the HTTP body or something…
What’s the best way to achieve this?
Marked As Solved
benwilson512
+1. I think the whole show/new/edit/etc paradigm is a good one to get going, but as you figure out the workflows that your users actually need to do I’m a big fan of just building those workflows where they make sense. If people want to go look at a transaction and seamlessly initiate a new transaction then I say put a form on show to make it easy.
Also Liked
benwilson512
It sort of sounds like you’re building one, so you could consider leaning into it. Maybe make the new thing a modal?
Stepping back to the link thing: Are you making a new transaction out of some sub-set of the outputs? Could you “compress” the information by, instead of sending the full 64 bytes instead send the “index” of the output? Eg if you have
Transaction-id: long-thing
outputs:
really-long-thing-1
really-long-thing-2
really-long-thing-3
really-long-thing-4
and you want to make a new transaction based on long thing 1 and long thing 4 you could put the transaction ID in the URL, and then just the indexes of those other values [0, 3]. The hashes are all sortable, and the transaction is immutable, so the combination of the transaction and the indexes should be deterministic. This should dramatically increase how many things can fit in your URL.
Of course your final option here I suppose is to use send_event to push a message to JS, and have the JS shove the data in local storage keyed off the transaction id.
benwilson512
Gotcha. Does the link need to take them to a totally different live_view or could it be a patch? You could have the selection content be a component with a form or something, and then when you submit that form, the liveview can hold onto that data in its state, and then render the next “step” of the form, and save the chosen contents in a hidden form field or just in its process state.
RooSoft
You are right to think that those 64 byte hashes can be reduced to an index… they always show up in the same order in a given transaction. That would make it possible to potentially create a querystring carrying that info in a pretty compact way. Still, somebody made a crazy transaction with ~1000 inputs a couple of weeks ago, and that would still break the ~2000 bytes URL size limit with the concept we’re talking about.
I will sleep on this, the idea of a wizard could also be a good one… I am just keeping the focus on the least amount of operations to get the job done, so most users end up thinking it feels natural.
Thank you ben, you help is very enlightening!
Popular in Questions
Other popular topics
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
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









