DoneJS Contributors Meeting – 2018-01-05

1

Please add topics for discussion (and your status if you’re a contributor).

LIve stream:

Attendees: @chrisbitme, @pYr0x, @phillipskevin, @m-mujica, @matthewp, @cherif_b, @chasen

Topics:

How should we handle can-migrate for 3.0 -> 4.0?

  • Ideas: different can-migrate packages, different versions of can-migrate for different migrations, different transforms for different upgrades, etc.
  • Agreed that we should only have one version of can-migrate and include 3.0 and 4.0 specific transforms, e.g. can-migrate --transform upgrade/can-4.js

Easier compatibility with a can-3-4 package:

  • Discussed whether we should include the inserted and removed events with can-stache-bindings because it already includes the enter event
  • Decided to remove the enter event from can-stache-bindings by default
  • Agreed to create a separate, namespaced/versioned compat package that would only add the events once

Julian’s tweet about CanJS having a component framework:

  • Lots of great discussion, but to summarize a potential next step: create a list of components that would be good to show how to build in our recipes/guides, then elicit the community’s help in building out the examples

Epics & issues:

2

Last Week:

Next Week:

  • Making can-component default to using DefineMap for ViewModels and stache for views
  • DoneJS Silicon Valley
  • Cleaning up more docs for 4.0
  • Releasing 4.0 ?
  • Working with Forms guide ?
3

Last Week:

  • Worked on upgrading bitballs, found several bugs as a result.
  • Fixed nodeList bugs in can-view-import and can-view-callbacks.
  • Finished bitballs except for a prod issue.
  • Fixed live-reload bug in Chrome 63.

Next Week:

  • Take other can 4.0 issues
  • Maybe start working on the can-element API again.
4

Last Week

  • Worked on getting can-stream-kefir integrated with can-debug
  • Worked on getting can-observe computed getterr integrated with can-debug
  • Worked on making sure slim builds worked when can-import is used

Next Week

  • Set up the slim build in one of our applications (like bitballs) to
    make sure there are no lingering issues.
  • Probably help with 4.0 issues
5

Topic:

  • how should we handle can-migrate for 3.0 -> 4.0?
6

Topic

  • Easier compatibility with a can-3-4 package.
7

Last Sprint:

  • Focused on some routing issues for the tech-overview guide
  • route.register(rule [,defaults])
  • route.data = document.querySelector("root-component')

Next Sprint

  • Move to can-connect on the tech-overview guide
  • can-set
  • Release 4.0

Topics

8

Last couple weeks:

Next week:

  • Working on a client project and conducting a user study; will help with 4.0 whenever I can
9

A bit surprised to see inserted and removed events being removed in 4.0. We use it a lot, so very interested in getting some info or “design pattern” on how to replace it.

What about the init event?

10

We’ll need to write this up more thoroughly in the migration guide and/or in the docs (we talk about it a little bit in the Lifecycle Hooks section here), but some quick notes:

  • They’ll be removed by default, but we discussed making a package to easily add them back for components that use them so migration is easier
  • There’s a new connnectedCallback API that is similar; you return the teardown function, which means you don’t have to store your listeners on your VM to tear them down on removal.
  • I think this is similar to the init event, just later in the component’s construction (after insertion).

Hope those points make sense. Out of curiosity, what are the most common things you’re doing with inserted/removed?

11

Also, some more issues kinda related to this topic (both for can-define):

12

In short, the goal is to migrate code that belongs in the view-model to the view-model. I’d say we haven’t totally settled on what the final result should be in 4.0 yet. The following is what I think an ideal scenario might be …

For can-component, there’s different layers of where logic should exist:

  • the component itself (the events object of Component 3.0)
  • the view-model

In an ideal world, I think the component itself would only exist to wire up view-models to non-dom views that can’t be done through can-stache. Widget libraries like google maps are probably the best example. For example, can-component needs to call goog.map.doSomething() when a viewModel property changes or a viewModel method when something happens on the map.

To support this, we probably need a Component.prototype.connectedCallback() along with the old events object. This would be used for inserted behavior in the scenario above.

Also in an ideal world again, the view-model would be pure (no DOM). Many of the uses of inserted and the events object should be put in the view-model in 4.0 (hopefully with value). For example, if you previously used events to implement a nameChangedCount like:

events: {
  "{viewModel} name": function(){
    this.viewModel.nameChangedCount++;
  }
}

You should be able to do this in 4.0 like:

DefineMap.extend({
  name: String,
  nameChangedCount: {
    value(resolve, listenTo){
      var count = 0;
      listenTo("name", ()=> { resolve( ++count ) })
    }
  }
})

We’re moving logic like this in the view-model where it belongs. This is a great thing IMO.

My big lingering question is what to do with something like a slider: https://github.com/canjs/canjs/blob/debug-guide/demos/technology-overview/component-slider.js#L11

Here I’ve made the VM bind directly on the element in its connectedCallback. I’m not sure this is right. Should this code still be in the component? What’s the point of having a VM if its going to need a DOM element to be tested? Maybe special events are what should happen here? This is currently where CanJS doesn’t have clear answers.

13

@chasen We mostly use it to set the element on the viewmodel:

"inserted" : function() { 
  this.viewModel.element = this.element;
},
"removed" : function() { 
  this.viewModel.element = null;
}

@justinbmeyer the listenTo function looks great!

But sometimes you just want to start something (like an ajax request, or some calculation for the width of the element, …) after the element is inserted, no?