I'm very new to Vue and have been given a task of looking at creating some Vue widgets that could be embedded in a couple of existing non Vue legacy web applications. The idea is that we would create a library of these widgets which could be then embedded in either of the legacy applications and eventually we might migrate the entire apps to Vue.
I've been searching for the best way forward and I am a bit confused. I guess these are my questions:
Do I need to be thinking Web Components here or can the widgets be actual Vue applications that we embed somehow?
If the widgets should be created as Web Components is there any difference between using the Vue/web-component-wrapper or the vue-custom-element library?
Whichever option we choose can we make full use of features that you would use in any normal Vue application - Vue router, Vuex for state management etc (and can state be shared across those widgets)?
Would the widgets need to be fully styled or would it be best practice to leave all the styling of the components to the parent app (or a combination of the two)?
I've never done anything like this before (as you can probably tell!) so any guidance or advice or pointers to examples would be appreciated.
** Update **
I found this article which I think is the direction I need to go in https://itnext.io/vuidget-how-to-create-an-embeddable-vue-js-widget-with-vue-custom-element-674bdcb96b97
There are three distinct (but quite similar) cases:
web components
They are supposed to be an encapsulated web fragment. If you want, it's a smarter alternative to <iframe>s. Its main use case (and what it was designed for) is to display ads in a page and guarantee the host can't mess with its internal logic and rendering.
custom elements
These are, simply put, declared and registered custom HTML tags. The advantage of using them is being able to mark them as off-limits in any outer framework, stating: "this custom element is not one of your custom components, treat it as an HTML tag".
framework components
By default, modern JS frameworks (Angular, React, Vue) use this pattern internally: their internal components look like custom elements (case 2). But they are not. They are just internal conventions, without ever making it into the HTML markup output of the app.
Here's what happens internally: when the template is parsed, if an unknown HTML element is met, the framework assumes it's one of its registered components. If it is, the tag is not rendered. A new instance of that component is created and the tag is replaced with the contents of the component's template (or the result of its render function).
All of the above frameworks, when running into an unknown html tag that is not a registered custom component will issue a warning along the lines of "hey, did you forget to register this component?". Unless it's registered as a custom element (case 2) - in which case they treat it as as such: an HTML tag.
Vue handles all of the above with grace. What you choose for your widgets largely depends on context and desired end result.
Here are the answers to your questions:
Do I need to be thinking Web Components here or can the widgets be actual Vue applications that we embed somehow?
You shouldn't go with Web Components if you want to be able to style them from the context.
If the widgets should be created as Web Components is there any difference between using the #vue/web-component-wrapper or the vue-custom-element library?
Yes, there is. #vue/web-component-wrapper produces web components (encapsulated DOM framents).
vue-custom-elements declares and uses custom elements (custom HTML tags). Their content is HTML markup (not encapsulated). The advantage of using custom elements is being able to inform outer frameworks: don't treat this custom element as one of your own components, it's handled by something else (Vue, in our case). Treat it as HTML markup.
Whichever option we choose can we make full use of features that you would use in any normal Vue application - Vue router, Vuex for state management etc (and can state be shared across those widgets)?
Yes. Whichever option you choose, you're still using JavaScript (every widget/app has unrestricted access to the entire context). You can also inject dependencies into your widgets, allowing them to communicate (by modifying the same external dependency - a router, a state management module, etc...). This is pretty much the standard mode in which every Vue instance normally operates. In simpler words, a Vue (sub-)component can function without a parent component and is, essentially, a Vue app. (or, if you prefer, every Vue app is a Vue instance and all of its sub-components are also Vue instances).
Would the widgets need to be fully styled or would it be best practice to leave all the styling of the components to the parent app (or a combination of the two)?
It's entirely your code design choice. It's easy to scope CSS in Vue. But there are great advantages in styling from above (DRY-er code). Also, having styles coming from context means less CSS rules applying, although that hardly qualifies as a performance issue. Obviously, take into consideration the answer to the first question.
I am currently working on a larger web application that is based on MVC Razor Pages.
For future components we want to use VueJS.
Now i have the following problem:
Parts of my Page get loaded and rendered then the VueJs instance attaches itself to the root element.
After a few (or a few more) seconds further data is retrieved and additional HTML-Snippets are injected into the DOM. Now this new injected HTML-Snippets do contain tags for some of our vue components, but they get injected by MVC Razor.
The root VueJS instance seems not no notice this changes in the DOM. Therefore the vue component tags in the new HTML do not get used/hooked by VueJS.
While I do understand the basic problem, I wonder whether there is a good workaround.
We can not just update complete parts of our web app to VueJS - they are to big and to legacy. But if there is no workaround for VueJS to detect those external DOM changes It will become hard to migrate our web app...
Thanks for every response in advance,
mitras2
I am trying to implement micro-frontends but my company is using React as the only front-end technology. I was hoping if I can do it by serving React components on a URL just as suggested in https://micro-frontends.org/ but it uses web components. Since all the ecosystem is on React can I serve a React component (and only that bundle code on a URL) like, https://my-website/components/table?theme="black".
Purpose of trying this:
Main repo will have most of the major dependencies already loaded. (no need of repeated code like react/react-dom etc)
Shadow DOM is creating event bubbling issues.
There are multiple repos for each team and all of them use same component library.
I'm converting an app (previously in jQuery/HTML/CSS) to React. The app has many modules, and each module has many submodules. I'm progressively trying to upgrade each submodule to React. The problem is that the sidebar is not in React.
There are two submodules which I have converted to React. The problem is when someone clicks on the sidebar link the entire page reloads and the resources going to fetch again.
If someone has open any one of the two pages that I have converted to React and then tries to move to the other page (also written in React) it should not reload for it. It should work like they are using the Link component to move.
I was thinking to mimic the feature by using the HTML5 history API. Using history.pushState did change the URL but react-router is not rendering the respective component on that URL.
I know there is some workaround with HashRouter, but instead, I want to use BrowserRouter.
For both pages, I'm rendering the same template from the backend and the routing logic delegated to react-router.
For started, I have created a codesandbox demo. Please tweak it and try to make it work when clicking on the (without Link) URLs as the Link component behaves in react-router.
I need to be able to dynamically include react components into my project, because I want to setup a plugin system and not every user has the same plugins/components enabled. Also they are/might get too big to submit all of them to every user. I tried to find out how to do that, but it seems that React might not support that use-case.
TLDR: How do I load React components from server when needed? Do I have to switch to Angular because react has no templateUrl equivalent?
React components are defined in JavaScript files, so you can load components in just as you’d load in any other JavaScript file. If you’re not using any sort of module mechanism like RequireJS, that might be as simple as injecting a script tag into the document. If you’re using something like RequireJS, you would just tell the loader that you want an extra module loaded.