Changing assigns inside form_for resets input values about drab HOT 16 CLOSED

But won't you still have the problem that the re-rendered inputs possibly lose focus / the cursor position? It's impossible to completely restore an input's state after replacing it.

These are the kinds of re-rendering provlems that drove me crazy when I was still using Backbone.js :)

It seems that the only real solution here is using a virtual DOM implementation (there are wuite a few out there not bound to a framework), or very exact data binding.

from drab.

Analysis

In the template there are two functions(macros) which uses assign:
form_for (@conn and @list - notice that @list is also inside it)
for (@list)

That means, when you poke the @list, both of the functions are re-evaluated, so everything in the form inputs is replaced with the default. The same is about the csfr token.

Workaround for now: do not use form_for, sorry :( but create form by hand, <form></form>

I have no idea (yet) how to solve it. I even don’t know if it is solvable, because this behaviour is a Drab’s core. Maybe I will need to add it to the limitations list.

from drab.

You could always replace form_for with your own version?

from drab.

Sounds almost like you need to make a virtual dom and 'patch' it onto the main instead of swapping. ^.^

Hmm, now that would be an interesting idea... A Drab.VDom library...

from drab.

Ah, my apologies. I confused two different issues. I need to double check this, however, but – if I remember correctly – when using protect from forgery forms are not validated because the csfr-token is changed after poke.

from drab.

Actually, it is not very complicated to fix.
Before update, I am going to collect all values on <input> fields, by name attribute. After the update, I will fill up the corresponding values with the saved ones.
This should fix the csfr issue as well, as it is stored in the hidden input.

from drab.

@eirikra
could you please test again with current master? I hope I solved the issue.

from drab.

Fixed in v0.6.0-pre.1

from drab.

Unfortunatelly, not so easy. It affects any <input> which is inside the expression, it doesn't have to be form_for.

<%= if (something) do %>
  <%= @some_assign %>
  <input>
<% end %>

Updating @some_assign with poke will re-render the whole if expression (as this assign is inside that expression). So anything user put in the <input> will disapear.

from drab.

Hmm, I really need to try Drab.Live in my setup. Just about everything is inside (usually multiple layers of) if/for/case and more...

from drab.

<input> values must survive refreshing the parent expression. Otherwise it is counter-intuitive. Drab.Live should be a black magic: things should just happen.

from drab.

If I'm not mistaken, we found that another workaround (if you don't want to build the form manually) is to not use the :protect_from_forgery plug. This might, however, not be something you'd necessarilty want to do...

from drab.

@eirikra but it still resets the values of <input>, doesn't it?

from drab.

It seems that the only real solution here is using a virtual DOM implementation (there are wuite a few out there not bound to a framework), or very exact data binding.

Technically Drab Live's special EEX handler is making a kind of virtual DOM. :-)

from drab.

Yes, there is a kind of virtual DOM there, under heavy rebuild now.

The root of the issue is how Drab searches for assigns in the expression. Compiled template like:

<%= if true do %>
  <%= @assign %>
<% end %>

contains two expressions (if and assign), and both of them contain this assign. When poking the @assign, drab re-renders both of them, because it is too stupid to recognize that it should be only done in the second one.

One of solutions would be to allow developer to choose where not to drab the expression with the custom marker:

<%/ if true do %>
  <%= @assign %>
<% end %>

For this, I made this PR elixir-lang/elixir/pull/6281. But it is not enough, it should be more clever choosing where to eval and replace expressions.

from drab.

it should be more clever choosing where to eval and replace expressions.

Such as by threading an environment through the calls to state what is required and what is not and so forth?

from drab.