Add prehtml-loader to documentation #211
Conversation
|
|
Codecov Report
@@ Coverage Diff @@
## master #211 +/- ##
=======================================
Coverage 95.28% 95.28%
=======================================
Files 5 5
Lines 106 106
Branches 21 21
=======================================
Hits 101 101
Misses 4 4
Partials 1 1Continue to review full report at Codecov.
|
|
We remove Thanks for the PR |
|
Mmmm… I am not a big fan of the new version, it breaks the retro-compatibility and is quite verbose (?) for the configuration for the webpack.config.js. In my opinion, it would have been better to have a js file to perform the preprocessing like I have done in my module, with a separate JS file executed at compilation time, able to modify directly the DOM with JQuery. This prevents the webpack.config.js to be way too verbose. I will downgrade my version of html-loader to keep using interpolate. |
|
But maybe should we speak about it ? |
|
@denis-migdal We add the example in README how to migrate from interpolation
Yes because it is breaking change
I don't recommend, html-loader@old doesn't work correction with webpack and other loaders, so you can get broken a code and a broken app Whu do you need interpolation, it was always bad idea and broken in many cases |
Yeah, but it would requires me to modify my existing HTML files (never a good idea in bigs projects), it is verbose in the webpack.config.js, and adds some features that, in my opinion, I handle better.
It works correctly for me. There were indeed some bugs because some loader started using ES6, but nothing I can't fix. There were a bug due to minimization, because you performed the minification before the interpolation (which was quite a strange thing to do in my opinion). I just disabled the minification and used html-minifier-loader.
It is not a bad idea, to the contrary. I use it to build HTML components I can include in other HTML page, or to build HTML templates (all at compilation time). And it works quite well. But maybe I should stop using html-loader and reimplements the require() and interpolation features. Note: I did not update the documentation for prehtml-loader, I will try to do it in few days to show you what I mean. Or I can demo it to you if you want, e.g. throw Skype. |
So it is breaking change, some features can't be compatibility with new version, don't forget
Please write here, it is allow to other developers read and find the best solution for their code base.
It is really bad idea, you try to implement |
Seems to work quite well for me. After, I did some fixes in my module, e.g. by resolving paths.
I strongly disagree, and I do not see why it would be dirty. Why should it be done in the client-side ? Better doing it on the server-side (like we would have done in PHP), so that we send all required content at once. template/slot seems quite interesting, and I could indeed use them in some cases in complement of what I am doing. Instead of making a "display:none" element and cloning it, I could just add an element. But still, I am able to factorize HTML files, add JS in the main bundle depending on the components I load in my page, and use their API in the JS of my main page. But maybe we are not speaking of the same things, I should do some quick example/documentation. |
See #206
This PR contains a:
Motivation / Use-Case
Cite new loader
prehtml-loaderin the documentation.See #206
Breaking Changes
No breaking changes.
Additional Info
See #206