#with does not seem to accomplish half of the two-way binding

1

I start with this.

Then I change each of the input boxes.

Notice that binding caused the text on the right to change in response to changes in only two of the inputs. That’s weird because the code is standard stuff.

Notice that the input tags are identical. The stache tags are identical. The only difference is that the second two items are part of an incoming array which I access with #each.

Note that…

  1. if I address the values with ‘loginUser.first’ instead of #with, it doesn’t work at all.

  2. if I change loginUser in some other way (eg, the console), both the input and stache item change in response.

My analysis is that the elements are wired up to the right thing. If I change the expected map, the changes pipe through to the UI. If I change the UI, changes are only reported back to the map for the dictionary item wrapped in an #each.

The creation of the map in question is a get().

because it is only retrieving one record. That record is, obviously, coming in as a nice list otherwise it wouldn’t show up in the editing form.

I note, finally, that when I get several users for the user management tool (this problem occurs on the profile editing tool), {{first}} is wrapped in a #each and works fine.

I am never a fan of attributing a bug to anything other than my own code. However, I have spent a couple of days trying to figure it out.

(I should note that, when I made the change handler parse the DOM and then actually wrote the data into the map, it worked fine. That is, when I took care of half of the two-way binding myself it worked. I don’t like that at all.)

I am now going to revise my code so that this thing is doing a getList() with a query that only retrieves this one item. Hopefully that will work.

If you can think of anything I can do to debug my code or yours, I would be grateful. In the meantime, I thought you should know.

2

I added this and now it works.

If I have the wrong idea about something, I would be infinitely grateful for advice.

3

Is this in 2.3? 3.0 has fixes for when the context needs to be observable. I’m not sure if this is that situation however.

Can you create this in a jsbin?

4

Also, what happens if you use ./replacement ?

5

re: try ./replacement

First, for clarity, I note the structure of login user is:

loginUser = {
	first: 'TQ',
	dictionary: [
		{
			replacement: 'first'
		},
		{
			replacement: 'second'
		}
	]
}

The problem is that the property ‘first’, at the top level of the object, is not binding properly, not ‘replacement’ in the dictionary list. Oddly, the elements of the list property ‘dictionary’ work fine.

I interpret this to mean the {{#with loginUser}} is broken and that {{#each dictionary}} is good.

In the spirit of your suggestion, I changed the code to

<input {($value)}="./first" fieldName='pattern'/>{{first}}

I also, though I know it’s pointless, tried {{./first}}, too.

In both cases, there was no change.

A detail that occurs to me to note is that loginUser is not in the parent component. It is needed in a few places so it is in app.js, two or three levels above this problem. Stache is finding it so I guess that’s not important.

6

re: Versions

I am using 2.3.

I need to get to 3.0 because of the process.platform.match() problem (it breaks my system in Webkit). However, the guide for doing tells me it is very arduous. It’s inevitable but I’m in the middle of something and can’t take what looks to be a couple of days to revise my code. The upgrade won’t happen for a couple of weeks. I will let you know what happens.