I'm using "react-i18next" to translate my Website and the translation files are in "/public/locales/{en|fr}/translation.json".
Problem: the files are cached and therefore when I update the translation values, the changes are not applied except if I clean my browser caches.
I guess, the solution is to add a hash in the name of these translation files during the start/build. This is what React already does for files in '/src' folder. How can I achieve that ? It seems that 'react-scripts start/build' abstract all the Webpack configuration.
You can host your translations on a dedicated path with the help of i18next-http-backend, like described here.
Alternatively, you could also make use of a professional CDN service like locize and fetch the translations via i18next-locize-backend, like described here.
Related
So I have an existing Create React Application and I want to be able to build a chrome extension to work in conjunction with it. Is there a away I can use webpack or something so that my extension kind "lives in" the React application? I want to do this because the existing application is quite large and I don't want to have to make changes (UI, api, or otherwise) twice. In my head I'm picturing it something like this:
- MyApplication/
- src/
- index.html
- App.tsx
- components/
- <bunch of other useful stuff>
- extension/
- index.html
- Extension.tsx (equivalent of App.tsx in react app)
Basically I'd be able to import whatever I need into the extension and run some command like build extension and it would bundle just the files and dependencies imported and necessary for the extension and output that to some directory I can upload to the Chrome Web Store.
I also briefly considered splitting the application into into something like MyApplication-core, MyApplication-web, and MyApplication-extension or something and just installing core in both web and extension but not sure if that's the best strategy or not. The first strategy I outlined seems simpler to maintain but I could be wrong.
Also, if there is another strategy I haven't thought of please let me know! Happy to add clarification if necessary as well! TIA!
Just build it and add manifest with required configurations. After this you will have posibility to load it as an extension.
I'm really a newbie in front-end development. I'm currently involved in a project that does front-end development. I hope I can explain this clearly.
Whenever I call http://localhost:8080/test, it is loaded by page1.jsp.
Now I would like to load a TSX file instead of a JSP. I tried changing my <welcome-file> from page1.jsp to html/js/page2.tsx in web.xml but I don't know why it is not working.
What happened is that a download file window will pop up instead of loading http://localhost:8080/test.
I placed the TSX file in the html/js directory because that's where the package for Typescript and React is located. By the way, the TSX file I'm talking about is a React component that uses Typescript.
Is it possible to configure the web.xml to render the TSX file? If not, is there any other way for me to load it?
Is web.xml still important if I want to load a TSX file?
No, for several reasons:
A .jsp is a "Java server page". You are probably running an application server like Tomcat (I haven't done that in fifteen years or so, so bear with me). It is compiled into a Servlet, which then runs to produce your page as output. Your .tsx file doesn't fit in that process.
Your application server probably has a directory somewhere where you can put static files that don't need to be run on the server side; see if you have a "WebContent" directory or so. In it you can place pure HTML files, Javascript files, fixed images and so on.
But if you put your TSX file there, your browser still won't be able to use it: browsers don't understand Typescript. Typescript needs to be compiled into Javascript, and if you put the resulting .js file there, then a HTML file could use it (with a tag), and that would work.
But your file isn't only Typescript, it's a tsx -- it probably also contains JSX, which also needs to be translated to Javascript.
There are also dependencies, like React, that you'll also need to download in your HTML.
On the whole this is what a bundler like Webpack is for (if you used create-react-app, for instance, you'll get a working Webpack configuration from the start). It can create a "bundle.js" containing all the Javascript needed in one file, including all the dependencies and all your TSX code compiled to Javascript.
Place that in a WebContent or similar directory, call that from a tag in some HTML file -- and you'll hopefully get a nice error message in the console that'll lead you to the first thing I forgot to mention :-)
I am looking for a solution that works with hugo server command. I am aware that I could create an additional .css file inside static/css directory and have it merged into the public directory with hugo command, however that does not work with hugo server unfortunately.
Thanks in advance.
On Hugo Pipes, you have an example with "Hugo Pipes Revolution -- A Hugo built-in asset pipeline" from Regis Philibert to give some examples.
From now on, Hugo will take care of bundling, minifying, fingerprinting our assets and even compiling our sass files! All of this without any external build tools.
So it works with hugo server.
You can define your method in assets:
These methods will only be available on files living in the assets directory: think of it as a static directory except the files will not be published by default.
Much like its static counterpart:
Its location is configurable with the assetDir key of your config.yaml. (will default to assets)
It follows the Hugo’s file unison logic.
Meaning, anything in your project/assets will override homonymous files of your theme/assets.
From there, you can adapt one of the sass centering techniques to apply it automatically on your images using pipes.
See "Centering With Sass".
There are several blog posts that explain why switching from grunt or gulp to building with just plain npm is a good idea for example this one by Cory Hourse or this one by Keith Cirkle. One thing these blog posts do not explain is how I can easily do environment configuration. For example a common requirement is to have different REST API locations. During development the server might be running on localhost:8080, but on production it should be accessed through a relative URL such as /api or /rest/api and the port or protocol are different for development and production.
There are several solutions for this. For example grunt supports template strings like <% %> and <%= %> and there are grunt or gulp plugins like in this question about grunt-ng-config. These solutions are specific to Angular (which I am using), but I am not necessary looking for an AngularJS specific solution.
I also know of the angular-environment plugin, but as far as I can see this does configuration at run time and I am looking for something that can do this at build time.
So what I am looking for is something that allows me to configure my application at build time either by replacing some template strings or by generating a Javascript file with some variables that I can read at run time.
One requirement is that it should be OS independent. So I do not want to use UNIX specific tools such as sed to rewrite a file. And due to different variable expansion (e.g. % vs. $) a solution should not rely on environment variables.
Is there an existing solution or a best-practice for this?
due to different variable expansion (e.g. % vs. $) a solution should
not rely on environment variables
this cuts off your best solution. Why not rely on env vars? node provides
process.env
to access env vars. You could create custom gulp / grunt tasks that use process.env instead of the "different variable expansions" you refer to.
You can use, for example, Jade templating to pass env var values to your HTML at build time. This would generate your index.html on the fly as part of the build process and add relevant classes based on env vars.
For example, according to the value of an env var you might set a class on the HTML tag.
This might reflect the customer.
Then you could have some CSS
.customer1 .myimage {
background-image: url("customer1.png");
}
.customer2 .myimage {
background-image: url("customer2.png");
}
or you could use JavaScript to detect which class was added to head during the build.
Like most js web apps we have a config.js file that contains global config information about the app, base api urls and such. These values are often different in local development than in production.
I've looked at answers like: Development mode for AngularJS using GruntJS, and also things like grunt-replace for creating an on-the-fly config file.
My issue is that the "development" part varies from developer to developer, we all need a version of the API setup so the base api urls will be different. I'd like to allow each developer to override specific variables in the config in a way that doesn't require them to commit that info to the git repo (I agree that this isn't best practice, everything should be in the repo, but as this is only 1/2 variables for this project I can overlook it)
Any ideas on how to achieve this setup?
You can use grunt-preprocess. I would have production (and dev-server, etc) values in a file, say env.json. You could use grunt to look for an optional file, say overrides.json or developer.json, which would extend/overwrite the values from env.json.
var envFile = require('./env.json');
You can create command line options to grunt with grunt.option, e.g. var env = grunt.option('env') || undefined;, which could be used to turn off overriding.
You can get data from the optional file using fs.existsSync:
var fs = require('fs');
var developerFile;
if (fs.existsSync('./developer.json')) {
developerFile = require('./developer.json');
}
The simplest way to define the grunt-preprocess context would be to use the developer.json file if present, or the env.json file if not:
context: developerFile ? developerFile : envFile;
This requires the developer file to be complete. An alternative is to extend the envFile with options from developerFile if it's present.
In my project, we use different config files (which are basically files with JS object). So every developer has his app/configs/developer/config.js file, which is not comited in the source control, so every developer has his own setup. Project uses link to app/scripts/config.js by default and this file is just a soft link to developers config file. However, there are also app/configs/staging/config.js and app/configs/production/config.js files, which are replaced when using gruntjj to build project. Those configs are just copied to build solution instead of soft linked file.
I hope that makes sense..