Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data Binding #1

Open
quigleyj97 opened this issue Feb 3, 2019 · 0 comments
Open

Data Binding #1

quigleyj97 opened this issue Feb 3, 2019 · 0 comments

Comments

@quigleyj97
Copy link
Owner

My over-arching goal with this library is to achieve a full model-view-viewmodel framework that bolts onto Phosphor and the DOM. But what's missing right now are viewmodels and binding.

Consider in XAML, you have:

  • The View (written in XAML)
  • The Viewmodel (A code-behind associated with the XAML, written in a CLI language like C#)
  • The model (Any set of objects implementing INotifyPropertyChanged)

With this split, bindings can be expressed between the view (or viewmodel) and the model, without encumbering the model with the concerns of XAML-land.

I'm not sure this is possible to do so elegantly in JS, but that's not to say it isn't possible. I have a few mental models for this:

  1. Models must subclass some abstract NotifyPropertyChanged, and the framework will use that for binding sources
  2. Models must be passed through some proxy generator, that will create get/set wrappers around a set of properties to achieve the same effect as NotifyPropertyChanged
  3. Models must be immutable or observable

3 is the approach that React and various state stores (like Redux) take, while Angular takes a bit of a hybrid of 3 and a top-down change detector. I'm against the change detector path since it requires a leaky DX (developers must know the caveats to avoid them), and practically would require computationally intensive diffing.

I like the "easy" nature of 2 but it still feels "wrong" in some sense, that models (or their consumers) have to specify what to observe. This complicates dynamic bindings.

1 is, I think, the most straight-forward but rather alien to the front-end world. It also requires that models be written with that in mind- we can alleviate the concern with some fancy decorators but at the end of the day you still have to consume a library-specific class to make it work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant