Would it be technically possible to implement a loader for Webpack that takes advantage of HMR to use with Polymer that preserves application state, like the one implemented for React, VueJS (github.com/vuejs/vue-loader) or Angular (github.com/yargalot/Angular-HMR)?
It would help a lot during development not to reload the whole application when you make changes a file in a polymer component.
AFAIK there is no easy way to do Webpack based hot reloading of Polymer elements.
This is due to the fact that web-components/Polymer import dependencies differently (using HTML imports) compared to the Webpack based stacks (using ES2015 modules and loaders). See also this issue.
There are efforts tough to implement the HTML imports using ES2015 modules once the spec is finalized (this might take some time tough).
If you use redux for application state management, and keep your Polymer elements as stateless as possible, you could at least suse HMR for your reducers which help during development.
For combining webpack + polymer you could check out this or this repo.
Related
I used three.js, gsap, and mobx(a global state management library). Can't I just call this a vanilla JS project?
Vanilla JS is a way of saying that the Javascript code is written without any libraries or dependencies.
Since you used three.js, gsap, and mobx, your project is not vanilla JS.
If I was looking for a job and a potential employer claims I'd work on an vanilla js project, I would not feel deceived if:
the overall structure of the project is not dictated by the library (which excludes angular, react, etc.).
used libraries have a limited scope and therefore are more or less easily exchangeable (you can switch from chart.js to d3.js)
I can understand, reason about and write code in an application logic module without looking up any documentation for the libraries used by the other modules (that's decoupling)
the removal of a library does not force you to rewrite your whole codebase
There is an exception to the last rule: legacy codebases that depend on libraries like jQuery or underscore: I'd call a project "vanilla" if the team is committed to remove these dependencies and new modules are written without these dependencies.
In your case presentation (three.js) and animations (gasp) should be decoupled from logic. But MobX seems to be the deal breaker: it plugs deep into your classes and logic. This is not vanilla. In order to understand your code, a new developer not only has to look at your code, but also at the documentation for MobX.
Allthough MobX says "MobX is unopinionated and allows you to manage your application state outside of any UI framework." The first example they present is obviously react code, which repels me.
My company has a few different websites, mostly with a react front end but a couple without.
We want to build a cookie bar that can just be imported and used anywhere...basically it should be framework independent and ideally an npm package.
I'm not entirely sure if this is possible but I had the idea to construct the cookie bar package with react...it would be super simple, just a few components with jsx and styling and once that is all done, use webpack to compile it all into vanilla javascript that is independent of react and can just be inserted on any site with any or no framework.
All of the html of the cookie bar (that would have originally been written as react components / jsx but then compiled into vanilla JS with webpack) which will then be injected into the html of the website where the script is included.
Is this possible?
All I can find online is people making react components as npm packages but this is not exactly what I am looking to achieve.
Thanks in advance!
This is absolutely possible.
If the target page doesn't have React in it at all, you may want to bundle it as a tiny app and mount it as in the answers here. If it does have React, you can probably find away to use the existing React by putting it on window in the other code (import React from 'react'; window.React = React.
For bundling a single component or a few components, you may have better luck with Rollup than Webpack (they have different use-cases; both are bundlers, but Rollup has some niceties for bundling libraries specifically). This example may be useful (it also includes Sass, Storybook, and some other extras that you might or might not need). This would give you more flexibility and possibly smaller bundles, but would mean you'd still need a React app to actually import and use the components, as above.
Since your project scope is quite small it should not import or embed the whole react library.
I strongly encourage you to check Preactjs (https://preactjs.com/) which lets you write your code in JSX but has a much lighter footprint (3kB atm). Your component will load way faster, especially for mobile users
Then bundling with tools recommended in the other answers (rollup is great) is the way to go
I have gone through this article : https://www.reddit.com/r/Angular2/comments/6a678s/primeng_vs_material2/
In the comment they mentioned we can use Prime Ng and Angular material
together in app. In PrimeNg components are standalone modules mostly so you can add only the ones you need and same is true for Angular material after couple of updates.
My question is... Can we use multiple number of libraries as many as we want with Angular app Like: PrimeNg, Angular material, Fuse and many more. Without affecting the performance or size of the build, because Tree shaking will take care of it.
Basically I want to use Material only for designing layout and some look and feel that.
Also, Does angular(5/6) supports 100% tree shaking or still we need to use Rollup.js ? Gone through multiple article but not sure yet.
When you build an Angular app with production flag, every component, service, directive or pipe is referenced at least once (in #NgModule annotations). At the end of the AOT compilation, the compiler removes these annotations and after that it also removes unreferenced things.
Source
That said, every Angular Material component is a module, which gives you fine grained import of the library.
I don't know PrimeNg, but from what I quickly searched and as you already know it seems to have one module per component too.
Using both libraries should not affect bundle size nor performance, but you should be aware that the "look and feel" differs from UI library to UI library
Is there a standard way to get React components dynamically from the server in order to render them at the client from already rendered components on demand? In other words, an already rendered component would return the ajax-received component when it will be re-rendered from the render() method.
With RequireJS and I think Browserify (using an extra package), scripts could be requested asynchronously. Currently I use webpack to transpile ES6 with Babelify.
My use case is that I want to create some sort of wysiwyg editor, and in theory there will be a repository of react-widgets that I would like to run on demand in an iFrame.
Thanks
If you are using webpack already you could look into the require.ensure functionality.
See: https://webpack.github.io/docs/code-splitting.html
This creates split points in your code without you having to do all the heavy lifting footwork.
I have a similar use case to yours and was able to use require.ensure successfully.
There are a few other tutorials/resources available:
http://jonathancreamer.com/advanced-webpack-part-2-code-splitting/
http://henleyedition.com/implicit-code-splitting-with-react-router-and-webpack/
https://www.youtube.com/watch?v=gvG8dSPCNno
Also, if you are building a wyisiwig editor you should check out draft-js.
https://facebook.github.io/draft-js/
Super cool and extensible, built right on top of React by the Facebook team.
If React offers DOM reconciliation, is it possible to dynamically reload component's code and re-render it after I edit it?
I'm looking for a solution that allows me to edit JSX file, save it, and have the component update itself in the browser, without reloading the page, unmounting it or losing its state.
Ideally this should work without browser plugins.
You can use react-hot-loader, a drop-in Webpack loader that enables live editing for React components in your projects. No browser plugins or IDE hooks required.
It marries Webpack Hot Module Replacement (HMR) with React.
You can use this if:
Your React components donʼt have nasty side-effects;
Youʼre willing to switch to Webpack for modules (it's not hard to switch, see the walkthrough);
You have a spare couple of hours (minutes if you already use Webpack).
How it works:
It uses Webpack HMR API to learn about the “module update available” event.
It changes React.createClass calls to special createClass and updateClass functions that store the component's prototype and later update it with fresh version;
When all prototypes are updated, it calls forceUpdate to re-render the components.
There is a demo video, an explanatory blog post and a React tutorial app fork with live-edit configured.
And it's all vanilla JS.
You can, and I created an example project demonstrating how to create these facilities for yourself using ES5 and RequireJS - it works with React and also with Backbone - it could probably work with Angular and Ember etc, as long as you use AMD modules and RequireJS.
Here's all the information:
https://medium.com/#the1mills/hot-reloading-with-react-requirejs-7b2aa6cb06e1
the basic steps are:
gulp.js watchers listen for filesystem changes
socket.io server in gulpfile sends a message to all browser clients with the path of the file that changed
client deletes cache representing that file/module, and re-requires it (using AJAX to pull it from the server filesystem)
front-end app is configured / designed to
re-evaluate all references to the modules that it wishes to
hot-reload, in this case, only JS views, templates and CSS are
available to hot reload - the router, controllers, datastores
are not configured yet. I do suspect all files could be hot reloaded with the only exception being data stores.
You can see an example project here:
https://github.com/ORESoftware/hr4R
but I recommend reading the article above first.
This is a simpler more DIY implementation of hot-reloading than using Babel/ES6 and React-Hot-Loader.
Webpack was not primarily designed for hot-reloading- if it were, hot-reloading would no longer be an experimental feature, nor would it using polling to see filesystem diffs, which it currently does (see my article).
The RequireJS / AMD spec was basically made for hot-reloading, if you think about it.