4

I've noticed if I do not use @observable in any of my web ui code all fields/members changes are picked up automatically with the data binding syntax.

The issue I run into is when picking one field in a class that extends WebComponent and applying the @observable annotation, now other fields dont bind correctly and display changes.

Is this a known issue or correctly functionality?

If I use @observable annotation once, should I be applying it to all fields?

adam-singer
  • 4,489
  • 4
  • 21
  • 25

3 Answers3

4

As mentioned in another post, you have the option of marking a class with @observable.

You're currently caught between observables and watchers. Watchers (and dispatch) are the old way, soon to be phased out. Observables are the new way. In order not to break old clients, we kept watchers in. If you used at least one @observable, then the watcher system is disabled.

The new MDV v2 implementation is getting ready. I suggest you use @observable for anything you want observed. Stop using dispatch() everywhere. Also, stop using observable top-level fields, because they won't be bindable into a node.

Apologies, things are really in a state of flux. I suspect things will settle quite soon.

I suggest reading more about MDV v2 here: https://github.com/toolkitchen/mdv/blob/stable/README.md to get ready for the change.

I suspect @observable will continue to be an option, so it's OK to keep using that now.

Seth Ladd
  • 112,095
  • 66
  • 196
  • 279
  • Thanks for the answer. I tried to move all web component classes to @observable by annotating the class. Did not have success with that route. I used a MVVM type of pattern for the application structure, not sure if that additional level of indirection is making the observable fail. Going to make a smaller sample to try and reproduce. – adam-singer May 07 '13 at 06:19
  • If watchers are kind of deprecated, shouldn't the generated samples use `@observable` instead? As it is, things are a bit confusing to be honest. – MarioP May 07 '13 at 08:32
  • @MarioP it is indeed confusing and as soon as the MDV v2 stuff lands, we'll clean up all the docs. Sorry for this period of duality. – Seth Ladd May 08 '13 at 03:53
  • @financeCoding hmm, if you can post your code somewhere we can try to help out. – Seth Ladd May 08 '13 at 03:54
  • Can you expand on 'Also, stop using observable top-level fields, because they won't be bindable into a node.'? In many of the 'A Game of Dart' tutorials the .dart files do not contain any classes so how would they have observables? – PeterVermont Jun 18 '13 at 14:20
  • @PeterVermont sorry for the cryptic comment. The MDV branch of Web UI is coming very soon. When that lands, you'll only be able to bind an object to a – Seth Ladd Jun 18 '13 at 17:18
3

From the documentation here, this seems by-design to me. The goal of the @observable is to mark that member as interesting for binding, unlike others.

You can also annotate the class itself with @observable if you don't want to annotate each field individually: Marking a class as @observable is the same as marking all of its fields as @observable

Zdeslav Vojkovic
  • 14,391
  • 32
  • 45
1

Today, I made a nice discovery about @observable: If you change an observed value outside of the component's dart code (using query("#component_id").xtag), the field needs to be marked as @observable - otherwise, the change to the value will not be noticed by the component.

Alternatively, after changing the value, one could call dispatch(). I'm currently testing what's faster, but I think it might be the annotation.

This is not a direct answer to the question, but it might be worth to consider this when deciding using the annotation or not using it.

MarioP
  • 3,752
  • 1
  • 23
  • 32
  • Thanks, I try to avoid having to do manual dispatch. In the particular situation I was dealing with it might be appropriate. – adam-singer May 07 '13 at 01:44