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

Move more things out of the template object? #756

Closed
Rich-Harris opened this issue Aug 6, 2017 · 4 comments
Closed

Move more things out of the template object? #756

Rich-Harris opened this issue Aug 6, 2017 · 4 comments

Comments

@Rich-Harris
Copy link
Member

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
Copy link
Member

PaulBGD commented Aug 7, 2017

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

@Rich-Harris
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

done in 1.40

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

2 participants