I am fetching namespaces for each component from a database that store JSON and adding them via addResourceBundle after init:
// Component
i18next.addResourceBundle('ar', 'topicNS', {
topics,
});
I would like to add these to the cache/localstorage. I am using the localStorageBackend to cache the static JSON resources, how can I add to the cached namespaces after init?
I have tried using the resourcesToBackend plugin, but am not sure how to make it work.
// i18n.js
backend: {
backends: [
LocalStorageBackend,
HttpApi,
resourcesToBackend((language, namespace, callback) => {
// ???????
}),
],
loadPath: `${process.env.PUBLIC_URL}/locales/{{lng}}/{{ns}}.json`,
},
Related
In app.module.ts I have the following:
#Module({
imports: [
...,
GraphQLModule.forRoot<ApolloGatewayDriverConfig>({
server: {
context: getContext,
},
driver: ApolloGatewayDriver,
gateway: {
buildService: ({ name, url }) => {
return new RemoteGraphQLDataSource({
url,
willSendRequest({ request, context }: any) {
...
},
});
},
supergraphSdl: new IntrospectAndCompose({
subgraphs: [
{ name: 'iam', url: API_URL_IAM },
],
})
},
}),
]
...
})
here getContext is just a regular function which is not part of nestjs context (doesn't have injection, module capability) like below:
export const getContext = async ({ req }) => {
return {}
}
Is there any way to use nestjs services instead of plain old functional approach to build the context for graphql gateway in nestjs?
Thanks in advance for any kind of help.
I believe you're looking to create a service that is #Injectable and you can use that injectable service via a provider. What a provider will do is satisfy any dependency injection necessary.
In your scenario, I would import other modules as necessary. For building context, I would create a config file to create from env variables. Then create a custom provider that reads from the env variables and provides that implementation of the class/service to the other classes as their dependency injection.
For example, if I have a graphQL module. I would import the independent module. Then, I would provide in the providers section, the handler/service classes and the dependencies as an #injectable. Once your service class is created based on your config (which your provider class would handle), you would attach that service class to your GraphQL class to maybe lets say direct the URL to your dev/prod envs.
We've run into some problems for our MultiSite Spartacus setup when doing I18n.
We'd like to have different translations for each site, so we put these on an API that can give back the messages dependent on the baseSite, eg: backend.org/baseSiteX/messages?group=common
But the Spartacus setup doesn't let us pass the baseSite? We can
pass {{lng}} and {{ns}}, but no baseSite.
See https://sap.github.io/spartacus-docs/i18n/#lazy-loading
We'd could do it by overriding i18nextInit, but I'm unsure how to achieve this.
In the documentation, it says you can use crossOrigin: true in the config, but that does not seem to work. The type-checking say it's unsupported, and it still shows uw CORS-issues
Does someone have ideas for these problems?
Currently only language {{lng}} and chunk name {{ns}} are supported as dynamic params in the i18n.backend.loadPath config.
To achieve your goal, you can implement a custom Spartacus CONFIG_INITIALIZER to will populate your i18n.backend.loadPath config based on the value from the BaseSiteService.getActive():
#Injectable({ providedIn: 'root' })
export class I18nBackendPathConfigInitializer implements ConfigInitializer {
readonly scopes = ['i18n.backend.loadPath']; // declare config key that you will resolve
readonly configFactory = () => this.resolveConfig().toPromise();
constructor(protected baseSiteService: BaseSiteService) {}
protected resolveConfig(): Observable<I18nConfig> {
return this.baseSiteService.getActive().pipe(
take(1),
map((baseSite) => ({
i18n: {
backend: {
// initialize your i18n backend path using the basesite value:
loadPath: `https://backend.org/${baseSite}/messages?lang={{lng}}&group={{ns}}`,
},
},
}))
);
}
}
and provide it in your module (i.e. in app.module):
#NgModule({
providers: [
{
provide: CONFIG_INITIALIZER,
useExisting: I18nBackendPathConfigInitializer,
multi: true,
},
],
/* ... */
})
Note: the above solution assumes the active basesite is set only once, on app start (which is the case in Spartacus by default).
Is it possible to use next-translate in combination with a YAML loader? For example, I'd like to use yaml-loader.
I tried it myself with no luck:
// file: next.config.js
const nextTranslate = require('next-translate')
module.exports = nextTranslate({
i18n: {
locales: ['en', 'es', 'it'],
defaultLocale: 'en'
},
loadLocaleFrom: (lang, ns) =>
require(`./locales/${lang}/${ns}`).then((m) => m.default),
webpack: function (config) {
config.module.rules.push({
test: /\.ya?ml$/,
use: 'yaml-loader'
})
return config
}
})
the previous next.config.js configuration throws the following error:
Module parse failed: Unexpected token (1:8)
File was processed with these loaders:
* ./node_modules/yaml-loader/index.js
You may need an additional loader to handle the result of these loaders.
These are the steps to use YAML files instead of JSON files with next-translate:
Install yaml-loader:
yarn add yaml-loader --dev
Configure webpack to use yaml-loader. This is my next.config.js file:
const nextTranslate = require('next-translate')
module.exports = nextTranslate({
webpack: function (config) {
config.module.rules.push({
test: /\.ya?ml$/,
type: 'json',
use: 'yaml-loader'
})
return config
}
})
Do not use i18n.json. Instead use i18n.js. In my case I have two pages: home (/) and teachers:
module.exports = {
locales: ['en', 'es', 'it'],
defaultLocale: 'en',
pages: {
'*': ['common'],
'/': ['home'],
'/teachers': ['teachers']
},
// Transform YAML files to JSON objects
loadLocaleFrom: (lang, ns) => {
return import(`./locales/${lang}/${ns}.yaml`).then((m) => m.default)
}
}
And that's all! You can now use the human-friendly YAML format, instead of the machine-friendly JSON format.
just like what #Cequiel described, the solution is using webpack config in the next.config.js, but I have compatibility issues while using yaml-loader(0.6.0) together with next.js (12.1.0 which defaultly using webpack 5), I used js-yaml-loader (^1.2.2) works well.
I have a gatsby-theme React application that uses gatsby-source-graphql to fetch the data from my back-end application. I had set the refetchInterval: 20 in my gatsby-config.js file. My gastby-config.js file is as below
module.exports = {
siteMetadata: {
title: 'Gatsby Theme Mytheme',
...
},
pathPrefix: `/gtm`,
plugins: [
{
...
...
{
resolve: `gatsby-source-graphql`,
options: {
fieldName: `cms`,
url: `http://127.0.0.1:7000/api/graphiql`,
typeName: `CMSData`,
refetchInterval: 20,
},
},
`gatsby-plugin-sharp`,
`gatsby-transformer-sharp`,
],
};
When I run the application in the development mode (gatsby develop) I'm able to see (console.log) the changes made in the back-end CMS application after an interval of 20 seconds. But the changes are not able to see/display on the build (gatsby build). Therefore after the build, whatever I change in the backed it is not reflected in my front-end application. So how can I fetch the changes from the back-end application for my a gatsby build dynamically?
The component I use to fetch the back-end GraphQL data is given as
import { useStaticQuery, graphql } from "gatsby";
export function myComponent() {
const cmsMenu = useStaticQuery(graphql`
{
cms {
allMenus {
edges {
node {
menuName
}
}
}
}
}
`)
console.log("CMS menu from MenuProvider", cmsMenu);
}
I'm using DocPad to generate system documentation. I am including release notes in the format
http://example.com/releases/1.0
http://example.com/releases/1.1
http://example.com/releases/1.2
http://example.com/releases/1.3
I want to include a link which will redirect to the most recent release.
http://example.com/releases/latest
My question: how do I make a link that will redirect to a relative URL based on configuration? I want this to be easily changeable by a non-programmer.
Update: I've added cleanurls into my docpad.js, similar to example below. (see code below). But using "grunt docpad:generate" seems to skip making the redirect (is this an HTML page?). I've a static site. I also confirmed I'm using the latest cleanurls (2.8.1) in my package.json.
Here's my docpad.js
'use strict';
var releases = require('./releases.json'); // list them as a list, backwards: ["1.3", "1.2", "1.1", "1.0"]
var latestRelease = releases.slice(1,2)[0];
module.exports = {
outPath: 'epicenter/docs/',
templateData: {
site: {
swiftype: {
apiKey: 'XXXX',
resultsUrl: '/epicenter/docs/search.html'
},
ga: 'XXXX'
},
},
collections: {
public: function () {
return this.getCollection('documents').findAll({
relativeOutDirPath: /public.*/, isPage: true
});
}
},
plugins: {
cleanurls: {
simpleRedirects: {'/public/releases/latest': '/public/releases/' + latestRelease}
},
lunr: {
resultsTemplate: 'src/partials/teaser.html.eco',
indexes: {
myIndex: {
collection: 'public',
indexFields: [{
name: 'title',
boost: 10
}, {
name: 'body',
boost: 1
}]
}
}
}
}
};
When I run grunt docpad:generate, my pages get generated, but there is an error near the end:
/data/jenkins/workspace/stage-epicenter-docs/docs/docpad/node_modules/docpad-plugin-cleanurls/node_modules/taskgroup/node_modules/ambi/es6/lib/ambi.js:5
export default function ambi (method, ...args) {
^^^^^^
I can't tell if that's the issue preventing this from running but it seems suspicious.
Providing that your configuration is available to the DocPad Configuration File, you can use the redirect abilities of the cleanurls plugin to accomplish this for both dynamic and static environments.
With a docpad.coffee configuration file, it would look something like this:
releases = require('./releases.json') # ['1.0', '1.1', '1.2', '1.3']
latestRelease = releases.slice(-1)[0]
docpadConfig =
plugins:
cleanurls:
simpleRedirects:
'/releases/latest': '/releases/' + latestRelease
module.exports = docpadConfig