Remove relays

[nucleartide]

It seems like we don't really need relays. Here are some random supporting thoughts:

1. There's a circular reference between a changeset and its relays, which means we could maybe combine the two. This would also remove the possibility of an infinite loop.
2. Some conversation between @krishandley and @webark in Fix 229 relay objects #236.
3. @poteto's early work seems to use relays for nested get/set, which has since been succeeded by get and her ember-deep-set addon.

Without relays, _valueFor would look a lot simpler – not to mention easier to maintain:

let changes = get(this, CHANGES);
let errors = get(this, ERRORS);
let content = get(this, CONTENT);

if (isLeaf(errors, key)) {
  return get(errors, `${key}.value`);
}

if (isLeaf(changes, key)) {
  return get(changes, key);
}

return get(content, key);

I might be missing something though. Anyone have any thoughts on the matter?

[krishandley]

It would be nice to at least try and remove them. 👍

It might be a breaking change for anyone who is getting around the current issue of getting non relay objects like this.

changeset.get('changeset.date') => // moment()

But there could be a warning for keys starting with /^changeset./ to say you no longer need to do this.

[nucleartide]

@krishandley Great point, maybe we should use Ember.deprecate as well. Or since this is a backwards-incompatible change, we could just bump to 2.0.0.

[krishandley]

Bumping to 2.0.0 sounds good to me 👍

[webark]

Ya. I think it’s worth a shot. I started from the existing feature branch, so i never tried it without. I think maybe if you where to get the nested object, then start working off of that, you’d run into some issues with things. But definitely worth a shoot. The whole time i was finishing it out, i felt more like i was applying bandaids rather then fixing root causes, and thought that with nested keys the architecture would need to change a bit, but at that time decided not to take a new direction.

[webark]

And to clarify my previous point. I realized it might have sounded like I was absolving myself and pushing "the blame" up. That was not my intention. There are times when you come into a system or issue that is half complete, and it is the responsibility of the one who completes something to feel confident in it. Having the "applying band-aids" to patches (if you read #194 (comment) it will become clear of the lack of confidence in the course I was taking). But I just didn't want to have it be misconstrued that I was talking about anyone's work other than my own. (Probably didn't need to state this, but just wanted to be painfully clear as I reread what I wrote and saw that it could have been taken the wrong way, so wanted to clarify).

[nucleartide]

@webark Don't sweat it, if anything I shouldn't have been so hasty in merging the PR. We have a good grasp on the remaining bugs – and I'll be on holiday break soon – so let's try to get the next release out. 😄

@poteto mentioned something about unknownProperty and setUnknownProperty not working with nested keys, which motivated the relay implementation. I think set(obj, 'foo.bar.baz', 42) worked something like this:

foo = obj.unknownProperty('foo')
bar = foo.unknownProperty('bar')
bar.setUnknownProperty('baz', 42)

So yeah this needs some more thought. Any suggestions would be appreciated!

[nucleartide]

Going to close this, since I understand why we need relays now.