Move more things out of the `template` object?

[Rich-Harris]

This might be taking things too far, but it occurs to me that we don't really need the template object in a lot of cases. This code...

<div></div>

<script>
  export default {
    oncreate() {
      alert('hello');
    }
  };
</script>

...could become this:

-var template = (function () {
-  return {
-    oncreate() {
-      alert('hello');
-    }
-  };
-}());
+function oncreate() {
+  alert('hello')
+}

function create_main_fragment ( state, component ) {
  //...
}

function App ( options ) {
  // ...

-  var oncreate = template.oncreate.bind( this );
+  var _oncreate = oncreate.bind( this );

  if ( !options._root ) {
-    this._oncreate = [oncreate];
+    this._oncreate = [_oncreate];
  } else {
-     this._root._oncreate.push(oncreate);
+     this._root._oncreate.push(_oncreate);
   }

  // ...
}

We're already doing this for stuff like components — if we did if for computed properties, lifecycle hooks and so on, we'd end up with leaner (and more minifiable) code.

(Done naively, the resulting indentation would be all wrong, which 100% doesn't matter but would drive me mental. So I would want to reindent all the user code, unless someone can talk me out of that.)

[PaulBGD]

I feel like a JS compiler (closure compiler?) could optimize that out really easily..

[Rich-Harris]

Ideally, yeah, but neither Uglify nor Closure do, even in Closure's ADVANCED mode (it will mangle the property names but that's all).

[Rich-Harris]

Some further thoughts on this. It's not that uncommon to have computed properties like this:

computed: {
  c: (a, b) => a + b
}

In such a case, where we have an arrow function expression without a return statement, or where it's a [arrow] function whose only statement is a return statement, that could be optimised like so:

-var template = (function() {
-  return {
-    computed: {
-      c: (a, b) => a + b
-    }
-  }
-}());

// ...

App.prototype._recompute = function _recompute(changed, state) {
  if (changed.a || changed.b) {
-    if (differs(state.c, (state.c = template.computed.c(state.a, state.b)))) changed.c = true;
+    if (differs(state.c, (state.c = state.a + state.b))) changed.c = true;
  }
}

It's a little trickier in a case like this...

<script>
  const lookup = generateLookupSomehow();

  export default {
    computed: {
      thing: key => lookup[key]
    }
  };
</script>

...because lookup is declared inside the template IIFE. One solution to that would be to bail out. Another would be to always get rid of the IIFE, which is better because we actually run into the same problem with any functions (methods, helpers, lifecycle hooks etc) that use those local variables.

The challenge that poses is that we'd need to ensure imports were deconflicted with whatever variables were declared inside the <script> block. But that seems doable.

[Rich-Harris]

done in 1.40