Navigate to new page, sending some rather large info

Phoenix Forum Questions / Help
, ,
1

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?

2

A simple link is always a GET request, which does not have an HTTP body. Can you elaborate on your use case a bit more? What is the information you’re trying to send?

3

We’re talking about a Bitcoin transaction containing possibly hundreds of outputs that can be reduced to ~ 64 bytes each. So, that page would enable the user to select some to create a new transaction out of these.

Best case scenario, we’d then end up in a LiveView page with the :new live action, already knowing which of those previous outputs will serve as inputs in the new transaction.

It’s pretty much a chaining process, but with an arbitrary number of links.

4

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.

1 Like
5

So you’re in short suggesting that this could be turned into a wizard, right?

Could be… maybe I was trying to separate things too much…

Thing is, the original page was thought as a Transaction :show page… I was thinking about going towards a Transaction :new page… Maybe this process should start from something else, such as an output selection page, and start from there. It feels like an extra navigation step for the user, though.

Bitcoin is a complicated thing, and my goal is to simplify things.

6

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.

2 Likes
7

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!

1 Like
8

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

1 Like