Refreshing dropdown list without data loss

Phoenix Forum Questions / Help
1

Hi guys,

Quick (hopefully) question regarding an implementation. I have created a medical system, that includes patients, doctors, pharmacies etc. When adding a new patient, the form that appears includes a dropdown box that is populated from the doctors database table or pharmacy database table, and when the form is submitted, the doctor/pharmacy id is inserted with the changeset as a foreign key in the patient table. If a new patient arrives and their doctor/pharmacy iis not in the database, this must be made available in order for the patient changeset (and data) to be valid. Therefore before the patient form can be submitted, the doctor/pharmacy details must be registered in the system.

My question is this: How can I implement a way of refreshing the dropdown lists that are populated without losing the data currently on the form?

Thanks in advance for any help.

2

You can make a request with javascript to fetch new data.

2 Likes
3

Oh god. I was hoping for a nice “hold your hand” kind of solution

4

Well if you are needing to push the updates from the server (much more efficient than polling), then this is probably what you want if you want as much done as possible for you (It’s awesome):

If you are wanting to poll (less efficient) or just add a few things to HTML tags with almost no work (really, it’s amazing), then a client-side library like this is amazing:
https://unpoly.com

5 Likes
5

drab looks really cool. I can’t wait for an opportunity to try it out.

1 Like
6

The term polling traditionally (in web development) is used for a mechanism in which we request the database for a specific data with a known interval of time (like per second) when we don’t know if the new data is arrived or not, typically used in old chat or notification systems. I think unpoly works differently and have a wider usage.

7

Thanks for the suggestions, I’ll take a look!

8

The only definition of ‘polling’ that I know if is requesting if there are updates to something in an active fashion, the opposite of which is pushing where the information is pushed over some form of channel. :slight_smile:

1 Like
9

You’re right in that sense.
Which means drab uses HTTP server push (through websockets or server sent events) ?

10

It probably uses websockets.

1 Like
11

Drab uses Phoenix Channels, thus either websockets or server push depending on how you have it configured.

1 Like
12

The way it works (as defined at it’s hex page “access the User Interface in the browser directly from the server side”), it’s more suited for SSE, which is more efficient if the data flow is uni-directional.

13

It can flow both ways quite easily. You can, for example, decorate a button or text box and get events back on the server with the information. :slight_smile:

1 Like
14

Looks like it remembers the previous state of the app inside the browser and send updates depending on that previous state, or it works differently?

15

Very different. Drab for each session keeps a process running and it holds the state on the server, the client and that server process talk together to exchange information and perform actions. And as that server process is just a normal websocket connection you can even send messages to it just by broadcasting as normal and all, allowing for almost trivial updates to a webpage. :slight_smile:

1 Like
16

As in http/2? I don’t think http/2 is more efficient than websockets.

1 Like
17

I looked at the source code, it uses browser’s local storage and session storage to keep the state. So applications like those based on Meteor can easily be made if we use Drab.

A fantastic package! :+1:

18

I didn’t use SSE myself, but I heard about it way before HTTP/2 was there, but http/2 is more suited for SSE.

19

Only long enough to hold data to bring up the server connection. :slight_smile:

And yeah, Drab can use any framework, even at it’s most basic you can just send simple javascript commands without any fluff. ^.^

2 Likes
20

Yes, there is a concept of Drab.Store - it is kept on the client side and you may choose if it is on the local storage, session storage or just in the browsers memory.
You may also read values from Plug’s session.

But there is more opportunities to store the values :slight_smile:

You can keep the state in assigns. Yes, you can query and update Phoenix assigns, live. So, if you do something like <input type=hidden value=<%= @assign %>, you may get and set this value on the server side with Drab.Live.poke/2 and Drab.Live.peek/2.

value = peek(socket, :assign)
poke(socket, assign: "updated " <> value)

Also, you might just update any property with Drab.element.set_prop/2 and get it back it with Drab.Element.query/3.

{:ok, value} = query(socket, "#myelement", :myproperty)
set_prop(socket, "#myelement", mypropoerty: "updated " <> value)

Also, you might just run any JS from the server, so just set any variable with Drab.Core.exec_js/2 and get it back with the same function.

{:ok, value} = exec_js(socket, "window.myvalue")
exec_js(socket, "windows_myvalue = 'updated #{value}';")
2 Likes