I'm currently working on internationalizing a system built with single-spa (microfrontends) with applications written on Angular and React.
I started using i18next and it's going pretty well, however, I've found a problem when trying to share the i18next dependency between all the applications.
When two applications are mounted simultaneously on the view the one who loads last overrides the i18next instance and thus the translations for the first one are never found as they were not loaded on the latter.
Thanks in advance!
It is better that I18next will be initialized at the shell level with the shell namespaces, and each internal spa will add its namespaces to the shared instance.
This way you won't have duplication of instance & code.
You can use [i18next.addResourceBundle][1] in order to add translation resources that are related to the current inner app.
i18next.addResourceBundle('en', 'app1/namespace-1', {
// ----------------------------------^ nested namespace allow you to group namespace by inner apps, and avoid namespace collisions
key: 'hello from namespace 1'
});
Pass the i18next instance as props to the inner app.
// root.application.js
import {i18n} from './i18n';
// ------^ shells i18next configured instance
singleSpa.registerApplication({
name: 'app1',
activeWhen,
app,
customProps: { i18n, lang: 'en' }
});
// app1.js
export function mount(props) {
const {i18n, lang} = props;
i18n.addResourceBundle(lang, 'app1/namespace-1', {
key: 'hello from namespace 1',
});
return reactLifecycles.mount(props);
}
Hope that the idea is clear :]
[1]: https://www.i18next.com/how-to/add-or-load-translations#add-after-init
Related
We are trying to update a library and the newer version requires Vue 3 instead of Vue 2, namely tinymce-vue. Unfortunately, it is a company project using bootstrap-vue, which has no full compatibility with Vue 3 yet (bootstrap-vue3 is not production-ready and we use some components that are not migrated yet).
Migrating the full app to Vue 3 has been the main attempt. However, it does not allow to use the Bootstrap components in Vue 3, or if the compatibility mode is used, part of the app works but those that would require the component do not appear/work or then the other parts of the component needing Vue 3 are broken. Is there any way to provide maybe library-specific compatibility or what is the suggested way to proceed in this case when needing two libraries that require two different versions of Vue in the same component?
I am not sure if this question should be asked differently, it is my first question in StackOverflow, so please let me know if I need to reformulate or provide more details.
The problem is that Vue 2 and 3 applications are hard to impossible to coexist in the same project because they rely on vue package with the same name but different versions. Even if it's possible to alias vue package under a different name or use modular Vue (import Vue from 'vue') for one version and Vue CDN (window.Vue) for another version in first-party code, another problem that needs to be addressed is that Vue libraries need to use specific Vue version.
This requires to build and bundle sub-apps with their preferred Vue version and libraries, which is quite close to the concept of micro frontend applications.
Given that there is Vue 3 sub-app that uses Vue 3-specific library (tinymce-vue) and specifically written to expose all public API to communicate with the outside world:
let MyV3Comp = {
template: `<div>{{ myV3Prop }} {{ myV3Data }}</div`,
props: ['myV3Prop'],
emits: ['myV3Event'],
setup(props, ctx) {
const myV3Data = ref(1);
const myV3Method = () => {};
ctx.emit('myV3Event', Math.random());
// Component public api needs to be exposed to be available on mount() instance
ctx.expose({ myV3Data, myV3Method });
return { myV3Data, myV3Method }
},
};
// Sub-app entry point
let createMyV3App = initialProps => createApp(MyV3Comp, initialProps);
export default createMyV3App;
There is Vue 2 wrapper component that acts as a bridge between Vue 3 sub-app and the rest of Vue 2 app:
import createMyV3App from '.../my-v3-app-bundled';
let MyV2WrapperComp = {
template: `<div ref="v3AppWrapper"></div>`,
props: ['myV2Prop'],
emits: ['myV2Event'],
data() {
return { myV2Data: null };
},
methods: {
// Sync wrapper events
onMyV3Event(v) {
this.$emit('myV2Event', v);
}
},
watch: {
// Sync wrapper props and data
myV2Data(v) {
this.v3AppCompInstance.myV3Data.value = v;
},
myV2Prop(v) {
// Hacky! Better use data and methods from public api to pass info downwards
this.v3AppCompInstance._instance.props.myV3Prop = v;
},
},
mounted() {
// Vue 3 automatically translates onMyV3Event prop as myV3Event event listener
// Initial prop values make app props reactive
// and allow to be changed through _instance.props
this.v3App = createMyV3App({ onMyV3Event: this.onMyV3Event, myV3Prop: null });
// also available as undocumented this.v3App._instance.proxy
this.v3AppCompInstance = this.v3App.mount(this.$refs.v3AppWrapper);
// Sync wrapper data
// Hacky! Better use event from public api to pass info upwards
this.v3AppCompInstance._instance.proxy.$watch('myV3Data', v => this.myV2Data = v);
},
unmounted() {
this.v3App.unmount();
},
};
In case wrapper and sub-app need to be additionally synchronized based on specific points, e.g. provide/inject, template refs, etc, this needs to be specifically implemented. At this point it's no different than Vue 3->Vue 2 adapter or adapters that involve other frameworks (Angular, React).
In my Nuxt app I'm registering app services in a plugin file (e.g. /plugins/services.js) like this...
import FeatureOneService from '#/services/feature-one-service.js'
import FeatureTwoService from '#/services/feature-two-service.js'
import FeatureThreeService from '#/services/feature-three-service.js'
import FeatureFourService from '#/services/feature-four-service.js'
import FeatureFiveService from '#/services/feature-five-service.js'
export default (ctx, inject) => {
inject('feature1', new FeatureOneService(ctx))
inject('feature2', new FeatureTwoService(ctx))
inject('feature3', new FeatureThreeService(ctx))
inject('feature4', new FeatureFourService(ctx))
inject('feature5', new FeatureFiveService(ctx))
}
After doing this I can access any of my service on vue instance like this.$feature1.someMethod()
It works but I've once concern, that is, this approach loads all services globally. So whatever page the user visits all these services must be loaded.
Now I've 20+ such services in my app and this does not seem optimal approach to me.
The other approach I was wondering is to export a singleton instance within each service class and import this class instance in any component which needs that service.
So basically in my service class (e.g. feature-one-service.js) I would do like to do it like this..
export default new FeatureOneService() <---- I'm not sure how to pass nuxt instance in a .js file?
and import it my component where it is required like so...
import FeatureOneService from '#/services/feature-one-service.js'
What approach do you think is most feasible? if its the second one, then how to pass nuxt instance to my singleton class?
Yep, loading everything globally is not optimal in terms of performance.
You will need to either try to use JS files and pass down the Vue instance there.
Or use mixins, this is not optimal but it is pretty much the only solution in terms of reusability with Vue2.
Vue3 (composition API) brings composables, which is a far better approach regarding reusability (thing React hooks).
I've been struggling a lot with it and the only solution is probably to inject services to the global Vue instance at the component/page level during the initialisation (in created hook), another option is to do that in the middleware (or anywhere else where you have access to the nuxt context. Otherwise you won't be able to pass nuxt context to the service.
I usually set up services as classes, call them where necessary, and pass in the properties of the context which the class depends on as constructor arguments.
So for example, a basic MeiliSearchService class might look like:
export class MeilisearchService {
#client: MeiliSearch
constructor($config: NuxtRuntimeConfig) {
super()
this.#client = new MeiliSearch({
host: $config.services.meilisearch.host,
apiKey: $config.services.meilisearch.key
})
}
...
someMethod() {
let doSomething = this.#client.method()
...
}
...
}
Then wherever you need to use the service, just new up an instance (passing in whatever it needs) and make it available to the component.
data() {
const meiliSearchService = new MeiliSearchService(this.$config)
return {
meiliSearchService,
results,
...
}
},
methods: {
search(query) {
...
this.results = this.meiliSearchService.search(query)
...
}
}
As I'm sure you know, some context properties are only available in certain Nuxt life-cycle hooks. I find most of what I need is available everywhere, including $config, store, $route, $router etc.
Don't forget about Vue's reactivity when using this approach. For example, using a getter method on your service class will return the most recent value only when explicitly called. You can't, for example, stick the getter method in a computed() property and expect reactivty.
<div v-for='result in latestSearchResults'>
...
</div>
...
computed: {
latestSearchResults() {
return this.#client.getLatestResults()
}
}
Instead, call the method like:
methods: {
getLatestResults() {
return this.#client.getLatestResults()
}
}
I'm trying to use the google maps API at my vue2 project and I have tried some ways that have failed. After using the vue2googlemaps module and the node module from google I have decided to use the CDN directly and add it to the index page. My problem now is that to acced to the google object, for example, to create a Marker or something like that, I need to use this.marker = new window.google.maps.Marker() for example, but in the tutorials I have seen, everyone uses directly the google object and never uses that window. I can`t understand why it happens. It would be appreciated if someone shows me the correct way to import or use this library on google.
It's because your template's code is compiled and executed in your component instance (a.k.a vm) 's scope, not in the global (a.k.a. window) scope.
To use google directly in your template you could add the following computed:
computed: {
google: () => window.google
}
If your problem is not having google defined in the component's <script>, a simple solution is to add it as a const at the top:
import Vue from 'vue';
const google = window.google;
export default Vue.extend({
computed: {
google: () => google // also make it available in template, as `google`
}
})
An even more elegant solution is to teach webpack to get google from the window object whenever it's imported in any of your components:
vue.config.js:
module.exports = {
configureWebpack: {
externals: {
google: 'window.google'
}
}
}
This creates a google namespace in your webpack configuration so you can import from it in any of your components:
import google from 'google';
//...
computed: {
google: () => google // provide it to template, as `google`
}
Why do I say it's more elegant?
Because it decouples the component from the context and now you don't need to modify the component when used in different contexts (i.e: in a testing environment, which might not even use a browser, so it might not have a window object, but a global instead; all you'd have to do in this case is to define a google namespace in that environment and that's where your component will get its google object from; but you wouldn't have to tweak or mock any of the component's methods/properties).
I recently came across this blog post: Stop using Page Objects and Start using App Actions. It describes an approach where the application exposes its model so that Cypress can access it in order to setup certain states for testing.
Example code from the link:
// app.jsx code
var model = new app.TodoModel('react-todos');
if (window.Cypress) {
window.model = model
}
I'd like to try this approach in my VueJS application but I'm struggling with how to expose "the model".
I'm aware that it's possible to expose the Vuex store as described here: Exposing vuex store to Cypress but I'd need access to the component's data().
So, how could I expose e.g. HelloWorld.data.message for being accessible from Cypress?
Demo application on codesandbox.io
Would it be possible via Options/Data API?
Vue is pretty good at providing it's internals for plugins, etc. Just console.log() to discover where the data sits at runtime.
For example, to read internal Vue data,
either from the app level (main.js)
const Vue = new Vue({...
if (window.Cypress) {
window.Vue = Vue;
}
then in the test
cy.window().then(win => {
const message = win.Vue.$children[0].$children[0].message;
}
or from the component level
mounted() {
if (window.Cypress) {
window.HelloWorld = this;
}
}
then in the test
cy.window().then(win => {
const message = win.HelloWorld.message;
}
But actions in the referenced article implies setting data, and in Vue that means you should use Vue.set() to maintain observability.
Since Vue is exposed on this.$root,
cy.window().then(win => {
const component = win.HelloWorld;
const Vue = component.$root;
Vue.$set(component, 'message', newValue);
}
P.S. The need to use Vue.set() may go away in v3, since they are implementing observability via proxies - you may just be able to assign the value.
Experimental App Action for Vue HelloWorld component.
You could expose a setter within the Vue component in the mounted hook
mounted() {
this.$root.setHelloWorldMessage = this.setMessage;
},
methods: {
setMessage: function (newValue) {
this.message = newValue;
}
}
But now we are looking at a situation where the Cypress test is looking like another component of the app that needs access to state of the HelloWorld.
In this case the Vuex approach you referenced seems the cleaner way to handle things.
I am just getting started with Durandal.js so excuse me for the silly quesstion...
When a user makes it's first request to the app it is asked to choose a 'profile kind', and I need it to be accessible to every other view model in the web site, I first though of creating this property in the shell viewmodel, but don't how to do it.
How is the best way to store data in a Session like mode in a Durandal SPA?
Thanks!
Create an amd module for what data you need to store.
Then just require that module as a dependency for whatever other modules that need it.
Sort of like this:
session module
define(function () {
return {
someVariable: 'value1',
someVariable2: 'value2'
}
})
some other module
define(['session'], function(session) {
return {
getValue1: function () {
return session.someVariable;
},
obs1: ko.observable(session.someVariable2)
}
})
EDIT**
AMD modules are there to not pollute the global namespace of the window object. But if you would rather not require your session as a dependency and just access it through a global variable then that is perfectly fine.
you can declare it in your shell.js if you would like and do something like:
define(function () {
window.session = { someVariable: 'value1', someVariable2: 'value2' };
})
then inside some other module you can access the session object like so:
define(function() {
return {
getValue1: function () {
return session.someVariable;
},
obs1: ko.observable(session.someVariable2)
}
})
This information will not be persisted between page refreshes.. its only in-memory.
If your looking to persist the session data I would not look into persisting any information on the client unless you planned on making your app an off-line application.
An offline application is an app that works even w/out internet access. But if your app requires that the user is always connected to the internet then I would just store the session data on the server. So, just use web services to persist the session data and retrieve it.
You can tie the session on the server to the client by using a cookie.
As an alternative to Evan's answer, which is definitively the correct AMD approach... have you considered using a global object for that purpose?
in main.js
window.myApp = {
prop1: 'value',
subOne: {
prop1: 'value'
}
...
}
That will allow you to access the global myApp object everywhere. I know that some people will consider that as global namespace pollution and in general a bad practice, but in a SPA project (where you control window) I'd consider this still a viable approach.