[email protected] not working on client side. about diff2html HOT 25 CLOSED

nunjucks was added as a dependency for version 2.0.0-beta1. Can you confirm it was downloaded?

Are you requiring the code from src or dist? You should use src. dist is for the browser.

from diff2html.

I was using disted version. Maybe because I'm doing browserify on diff2html and nunjucks being browserified twice??

I will try to use src later and let you know

from diff2html.

I am currently using webpack for the dist version. And I am passing the parameter saying it is for WEB.

I am not sure if this creates any kinds of problems.

When running webpack I do this transformations:

    new webpack.NormalModuleReplacementPlugin(
      /(nunjucks)$/,
      'nunjucks/index'
    ),

    new webpack.NormalModuleReplacementPlugin(
      /(precompile|nodes|lexer|parser|transformer|compiler|loaders)$/,
      'node-libs-browser/mock/empty'
    ),

    new webpack.DefinePlugin({
      'process.env': {
        IS_BROWSER: true
      }
    })

And I also precompile the templates to dist/diff2html-templates.js

If you give me some tips about browserify maybe I can also do a dist with it (not sure if it makes sense)

from diff2html.

The problem is that for browserify nunjuncks in var nunjucks = require('nunjucks'); is provided by nunjucks/browser/nunjucks.js, browserify expects nunjucks to set external module and exports, but nunjucks/browser/nunjucks.js does not touch them, it just assigns its module to var nunjucks, and the module remains unconfigured. (I do not know yet how to solve this.)

from diff2html.

This is an open issue with nunjucks: mozilla/nunjucks#507

from diff2html.

Thanks for the discovery, I be keeping my eyes on that issue and upgrade diff2html accordingly.

from diff2html.

@orivej as I said in the previous answer if you use:

    new webpack.NormalModuleReplacementPlugin(
      /(nunjucks)$/,
      'nunjucks/index'
    ),

    new webpack.NormalModuleReplacementPlugin(
      /(precompile|nodes|lexer|parser|transformer|compiler|loaders)$/,
      'node-libs-browser/mock/empty'
    ),

    new webpack.DefinePlugin({
      'process.env': {
        IS_BROWSER: true
      }
    })

Webpack works just fine, is there any way to replace modules in browserify?

from diff2html.

I'm using webpack too; I missed that this snippet is something I should try to put into my webpack.config.js, rather than just something you use to build a release of diff2html.

I tried to include it as is, and observed that the build fails since the second plugin hides important modules unrelated to nunjucks. Need to figure out how to circumvent this…

from diff2html.

@orivej it is a really bad hack. I am wondering if nunjucks is going to give a lot of headaches.

from diff2html.

Sorry for being a bit away these last weeks. Is a pity that nunjucks have this issue which such a hacky workaround. We hoped nunjucks would make it easier to have better formatted and easier to maintain and override html but if is not working for us we might want to looks for alternative solutions. Do you guys see a value in using it at all? Other solutions were proposed, like using React components for the html.

I would like to know what's your opinion on this one?

from diff2html.

This seems to be really bad. @orivej @codingtwinky any suggestions about other options to move the html from the JS code?

I am starting to regret nunjucks. It nows seems even more complicated. Since we are only in beta for this we can roll back to other option.

from diff2html.

I don't know much about nunjucks so I can't do fair comparisons, but if you are looking for html templating frameworks isn't handlebars or mustache are the standard goto solutions?

from diff2html.

I will have to look into the way diff2html uses nunjucks to give an informed judgement.

from diff2html.

@codingtwinky thanks for the input. I will also take a look at thoose options a make some tests when I have some time.

from diff2html.

@rtfpessoa also, ECMAScript 6 allows multiline strings with backticks ( ` ). I've seen a lot of people using ECMAScript 6 and transpiling it with Babel to make it compatible. Is just something to consider maybe. I like React but I think it would be better to keep the project dependencies on the low and React is a huge dependency but that's just my opinion.

from diff2html.

Now I also think react is too much for the purpose.

I took a look at mustache and handlebars and both look good. Mustache seems simpler but you cannot have loops etc. For that reason Handlebars seems a good alternative since it is simple and has precompiled templates. I will do some tests and see if I find any other alternative.

In the meanwhile let me know if you have any other good suggestions.

from diff2html.

I have a couple more alternatives here (for no special order):

• hogan.js from Twitter
• dust.js from Linkedin
• pug.js influenced by Haml (previously named Jade)
• JsRender
• marko.js

From what I have seen hogan.js seems to be a good alternative to handlebars since it also implements mustache and is more lightweight.

Any thoughts @codingtwinky @orivej @pbu88 ?

from diff2html.

I have never done client side or web server programming in my life professionally, I'm just a backend data infrastructure grunt who have terrible habit of poking javascript open sources. But I did have lots fun with Jade and did like it alot as you can import and export templates with in the page really easily. I can't believe I have forgotten about it.

But my vote shouldn't count as much as others and other libs may have better features.

from diff2html.

I want something lightweight with just the minimum set of features.

I was trying with hogan.js but I am having some problems using the templates on the browser and on the node side at the same time.

from diff2html.

I think #69 fixes this issue, version 2.0.0-beta11, can you check?

from diff2html.

I had to add var Hogan = require('hogan.js'); to diff2html-templates.js to build a project using diff2html with webpack. try/catch around require in HoganJsUtils prolonged the time to debug.

from diff2html.

@orivej can you check it on 2.0.0-beta12 it should fix the problem.

Can you explain "try/catch around require in HoganJsUtils prolonged the time to debug." better. I am not understanding what you mean.

Edit: I think I might have underestimated this change. I need to take a better look at it.

Edit2: Tests are fixed, some kind of \n difference between before and after that change. Weird.

from diff2html.

As of 2.0.0-beta12, diff2html works as is.

With 2.0.0-beta11, templates did not render and there were no exceptions in the browser console, so I began debugging by examining if webpack produced sensible output: it was not obvious since it wrapped the contents of diff2html-templates.js with (function(global) {…}.call(exports, (function() { return this; }()))), and it was not until I removed try/catch from HoganJsUtils that I saw the cause of null rendering.

from diff2html.

@orivej just released 2.0.0-beta13, now I am considering that I will always compile the templates before release.

FYI, I have also been adding lots of more tests to the parser and the generators.
Specially the parser is now more stable and I fixed several corner cases.

from diff2html.

I am considering this fixed with PR #69

from diff2html.