Polymer: [Suggestion] Data flow design

[zaclummys]

I was thinking about new ways to write expressions that helps us improve designs like readOnly/notify.

Currently, Polymer has the following types of data binding annotations:

• {{expression}} upward/downward
• [[expression]] downward

_But what if we have a new type which only allows upwards data flow?_

• ((expression)) upward

It'd bring a convenient way of writing upwards expressions for when it's suitable, without having to adapt the components themselves with flags.

For example, an x-input that only exposes the value in its field. Or a x-fetch that exposes only the lastRequest. They will never receive these properties from host, so it wouldn't be suitable if they accidentally receive a default/new value.

In these cases, instead of prohibiting upwards or downwards definitely, let the developers decide _when/how/where_ it should happen. :)

[veith]

From an architectural point of view, this proposal makes perfect sense. There are many situations in which such controlled behaviour is required. At the moment we work around this problem with one component and use two variables.

Such a terminology like ((receive-only)) would offer significantly more and finer possibilities of expression for the developer.

desired expression

<x-fetch response="((response))"></x-fetch> 
````


*actual workaround*

//The non-return-valve component mimics the desired behaviour

```

[kevinpschaaf]

Thanks for the feedback. I agree that a third binding syntax would add semantic/readability value, since it would make it clearer to the reader which direction the binding is intended.

However in practice, this is almost never a correctness issue. In the <x-fetch> example, you would only _need_ that directionality enforced if _both_ a.) the host of x-fetch had an initial response value that would be pushed to x-fetch, and b.) if x-fetch's response property was not read-only. In this particular case neither of those conditions would make sense.

We're not inclined to add more features to the binding syntax of Polymer 2/3 at this point, so I don't think we're going to entertain making a change here.