how do I @observe objects which do not implement observe.Observable in polymer

Question

I use protobuffers for communication between my frontend end and my dart server.
Those objects do not implement Observable.

My dart-polymer object looks something like:

@CustomTag('user-address')
class UserAddress extends PolymerElement {

  @observable
  protobuffer.Address address = new protobuffer.Address();

My html-code looks something like:

<template>
  <form method="post" on-submit="{{doSubmit}}">
    <input type="text" value="{{ address.street }}" name="street">
    Your street is {{ address.street }}.

Because the protobuffer.Address doesn't implement Observable {{ address.street }} won't be updated.

I have found a few possible solutions / work-arounds, but I not happy with any of them:

• fork the protobuffer creation code [1] and adapt the output to mixin ChangeNotifier.
  I have already implemented this, but I am pretty sure that my changes won't be accepted upstream.

• convert the protobuffer objects to ObservableMaps. This wouldn't require any changes upstream, but we lose the type safety and have to convert from protobuffer → map and then from map → protobuffer.

• try to use Mock objects, and intercept setter calls. I haven't spent enough time to find out if this is even possible.

[1] Those protobuffer objects are automatically generated by protobuf-builder which uses the dart-protoc-plugin.

Answer 1

I know this may not be the answer you are looking for but I would really recommend that you make your data transfer object classes (the one you send across the wire) separate from your view objects classes (the ones supporting data-binding).

Having done a lot of MVVM pattern development I have found that this is always a good idea and worth the duplication that it creates. Forcing a single class to act both as a view object (data-binding to it) and as a data-transfer object (transferring it using eg. protofuf) usually just means a lot of trouble, especially as your application grows, the views become more complex, and the things you want to show on-screen will no longer map 1:1 with what you want to transfer.

Having separate classes with the single concern to support data binding will make your binding expressions much simpler. Because you can create properties freely on the view object without thinking about the data transfer, all your binding expressions will always be 1:1 to a property which makes troubleshooting data-bindings much simpler.

Answer 2

I would discourage using Mock objects. They use noSuchMethod which uses reflection/mirrors which will probably cause troubles regarding code size on the client side.

The only alternative solution is see is to create wrapper classes that implement observable.