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

Webpack loader announce #3

Open
blikblum opened this issue Jun 9, 2017 · 9 comments
Open

Webpack loader announce #3

blikblum opened this issue Jun 9, 2017 · 9 comments

Comments

@blikblum
Copy link

blikblum commented Jun 9, 2017

Thanks for your work.

Just like to inform that i created a webpack loader for incremental-bars: https://github.com/blikblum/incremental-bars-loader

An actual example of usage can be found at https://github.com/blikblum/marionette.renderers/tree/master/examples/idom-handlebars

@atomictag
Copy link
Owner

Awesome! Many thanks! Let me know if you find the library useful

@blikblum
Copy link
Author

blikblum commented Jun 9, 2017

I think it will help a lot of people to migrate for more performant rendering strategy

@atomictag
Copy link
Owner

atomictag commented Jun 9, 2017

cool. BTW, in case you try to get a reference to the current element from a helper - e.g. to do something a la innerHtml or to decorate the element being patched, IncrementalDom.currentElement()and IncrementalDom.currentPointer()are not going to help - because your helper is going to be called before the element is actually created. In order to do that you'll need to provide a (relatively trivial) extension to IncrementalDom in order to "pass back" the node returned by elementOpen, elementOpenEnd, elementVoid and text

@blikblum
Copy link
Author

IncrementalDom.currentElement()and IncrementalDom.currentPointer() are not going to help - because your helper is going to be called before the element is actually created

I managed to access the current element by putting the interpolation {{setInnerHTML short_bio}} after the element. But the issue is that calling skip gives an error because the the helper is called inside a IncrementalDOM.text call.

In order to do that you'll need to provide a (relatively trivial) extension to IncrementalDom in order to "pass back" the node returned by elementOpen, elementOpenEnd, elementVoid and text

I can not see how it could be done

AFAIK the only way to do that would be creating a way to put raw script in the code, something that superviews does with the <script> tag

@coldwhitelight
Copy link

Hello,

I've got a specific case, where 90% of the app templates will be precompiled but some may be compiled on page load or loaded from an external source (ajax) and compiled on the spot.

I already use incremental-bars with incremental-bars-loader for Webpack and it seems to work with this example:

// this is in my index.js

import IncrementalDOM from 'incremental-dom';
import Handlebars from 'handlebars/runtime';

// this is compiled by incremental-bars-loader.
var template = require("../templates/baselayout.tpl");

// This works.
IncrementalDOM.patch(el, template, {title: 'Test'});

However I cannot load incremental-bars to be used in browser in any way.
I know it's not supposed to be done that way, but is there any way I can still include it with Webpack? Or at least build myself a dist version of the script to include as an external?

Including it like that:

var Handlebars = require('incremental-bars');

gives me a lot of warnings and some errors:

> TypeError: Cannot read property '_' of undefined
(...)

> ./node_modules/handlebars/lib/index.js
require.extensions is not supported by webpack. Use a loader instead.
(...)

> client:147 ./node_modules/html-minifier/node_modules/uglify-js/tools/node.js
7:11-32 Critical dependency: the request of a dependency is an expression
(...)

Any help would be really appreciated, thank you.

@atomictag
Copy link
Owner

atomictag commented Nov 7, 2017

I personally don't use webpack so perhaps someone with more experience with that can chime in. I guess it's not a difficult task to make it work - given the very limited amount of dependencies.

OTOH, it may makes sense to use the standard Handlebars compiler for those 10% pages that requires on-the-fly compilation.

@coldwhitelight
Copy link

coldwhitelight commented Nov 7, 2017

Thanks,

It probably isn't difficult, but I'm starting out in this department.
I can't use standard Handlebars, as I want to forward the compiled template to IncrementalDOM.patch(), so I need it compiled by incremental-bars, not handlebars.

Unless there's a way I don't know about?

Edit: So there's no easy way to get a working incremental-bars.js file to include I suppose?

@atomictag
Copy link
Owner

well, you could use IncrementalDOM.patch(el,...) for idom-compiled templates and el.innerHtml = ... (or similar) for your html-string-compiled templates. That's by far simpler and more performant than any other option I can think of

@coldwhitelight
Copy link

coldwhitelight commented Nov 7, 2017

Allright, thanks for help, I'll try that!
Hopefully someone has an idea on how to make it work.

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

No branches or pull requests

3 participants