I am using Next.js' multi zone feature with a blog and web app so I can develop and deploy both apps independently. It was easy to set up by following their with zones example and I have set up a blog app at port 4200 and a web app at port 3000, which is working fine. Unfortunately I am encountering some problems that aren't described anywhere in their documentation (as far as I can tell).
First of all, I am also using their internationalised routing which is working fine, however when going to my blog app it appends the locale to the end of the URL. Imagine I am on localhost:3000/en and navigate to the blog app, then it will show localhost:4200/blog/en instead of localhost:4200/en/blog. Is there any way around this (e.g. by using rewrites)?
Secondly, I am working in a monorepo and have shared components between both apps, such as the header and footer, which obviously includes navigation. When I am on the blog and want to navigate to e.g. the /about page, then it will obviously navigate to localhost:4200/blog/about instead of localhost:3000/about. One solution is to check the base path in the navigation component and then prepend localhost:3000 to the href if the base path equals blog, but that refreshes the entire app and does not result in smooth navigation, so it's not really ideal. Is there anything else can I do about this?
Seemingly the multi zone feature is really only suitable for very small apps or I'm missing something. It seems others also have the same problem, if I am missing something, then the documentation could definitely be at the least.
Related
I was tasked with implementing an i18n for the company website. At present we are using Netlify with #netlify/plugin-nextjs, and I hit the wall when submitting a PR when I got an error saying that
Error: i18n support is not compatible with next export.
I have read several topics here and a few articles and I found one smart workaround https://dev.to/adrai/static-html-export-with-i18n-compatibility-in-nextjs-8cd
And other suggestions were to move to Vercel. Is this the thing I should consider? We do not use getServerSIdeProps anywhere, the website is fully SSG so what is the benefit of the next export over the SSG approach? Is SEO better with the next export?
Next-translate seems to be building pages in development on every page change so perhaps it is possible to build a separate page for every translation without the need for such a burden?
I think moving to Vercel would be doable but should I do that? Would this allow me to deploy the translation while saving the SEO that next export gives? Or should I go with the custom solution above?
Thanks
With next export you can generate static HTML pages (SSG) that can be served easily from any server of your choice, but this way you won't be able to use all of the features listed on this page:
https://nextjs.org/docs/advanced-features/static-html-export#unsupported-features
And other suggestions were to move to Vercel. Is this the thing I should consider? We do not use getServerSIdeProps anywhere, the website is fully SSG so what is the benefit of the next export over the SSG approach? Is SEO better with the next export?
When deploying to Vercel or Netlify you still have all the SEO benefits of statically generated pages (Either through Automatic Static Optimization or manual usage of getStaticProps) and full access to all Next features listed in the link above (including i18n). Hence, if you have static pages, next-export has no SEO benefits over deploying on Vercel/Netlify, as in both cases you will serve pre-rendered pages to users, but next-export just gives you better flexibility when it comes to deployment.
Next-translate seems to be building pages in development on every page change so perhaps it is possible to build a separate page for every translation without the need for such a burden?
As you mentioned, that's exactly what the example you linked above achieves: It pre-renders every page for every locale you have, which is also exactly what you'd get when deploying a Next app with a i18n package like next-translate or next-i18next on Vercel or Netlify.
I think moving to Vercel would be doable but should I do that? Would this allow me to deploy the translation while saving the SEO that next export gives? Or should I go with the custom solution above?
If you can, you should deploy on Vercel or Netlify to save a lot of time and get all the features like i18n out of the box. But, the example you provided above also makes i18n work with next-export so if you have a plain, static website that requires no other custom Next features like routing, middleware or Image optimization, it will surely work too if you don't want to deploy on Vercel/Netlify.
In my Ember app (actually mine is an engine within a host/parent app), I want to set the page title.
Now while I do
document.title = "Page title I want"
However, it gets overwritten by the host app i.e. what is set in the index.html
Where can I have the above code to set page title? Already tried adding in beforeModel, didTransition hooks, But that does not work.
I'd highly recommend standardizing across your app and all engines on ember-page-title. Which will allow you to add {{page-title "Blog"}} to a template. It has some additional features that are really nice when working in a larger app, but by delegating all of your title setting needs to a single addon you can have a standard API across your app and all engines for doing this task.
There are other addons that also serve this purpose, but this RFC has movement towards making ember-page-title the default for new ember apps.
I built a small site that uses gatsby for static content, but then for some content that needs to be rendered on the client-side, I'm using client-only routes in gatsby.
I am not sure I fully understand how this works though - Say I have a Header, Footer & a font that I am using in my static site. On my client-only routes, I am using the same Header, Footer & font. Will I benefit at all from having used these elements in my statically components previously? Is the font being loaded anew, for example?
Basically, I would like to know what Gatsby-features my client-site content is losing out on now, and what I should maybe attend to a bit more, since Gatsby won't be handling this for me anymore. Especially in terms of pagespeed.
Yes you should benefit from having used those components and fonts already.
The React components that are being re-used will already be in a JS bundle that you have shipped to the user and shouldn't need to be fetched again. Likewise with the font files - but these will be asset files - not in a JS bundle.
The best way to see what is being fetched will be to test it out in a browser.
Load a static page
Open the Network tab in dev tools
Navigate to a client-only page and check for network activity
While those assets shouldn't be fetched twice I can imagine some instances where an incorrect setup would fetch them twice - so best to just double check.
Will I benefit at all from having used these elements in my statically
components previously?
The answer is yes. Gatsby works with #reach/router under the hood so you will have all benefits of it no matter if you use client-only routes or not.
In other words, the trickiest part of using client-only routes is the internal routing, for your site, in that scenario, Gatsby will handle the routing internally since it extends from #reach/router, so the shared components (header, footer, etc) will only be rendered on-demand and will be shared across your site, no matter if it's a client-only route or a static page.
I would like to know what Gatsby-features my client-site content is
losing out on now, and what I should maybe attend to a bit more, since
Gatsby won't be handling this for me anymore. Especially in terms of
pagespeed.
Summarizing a lot, when a page loads, #reach/router looks at the path prop of each component nested under <Router />, and chooses one to render that best matches window.location. So you will only render the needed code on-demand.
In terms of page speed, your site won't be affected because the site keeps being "static" and pre-mounted once the build is done. The only "negative" part of using client-only routes (if you want to say that) is the SEO part since they won't be intercepted by Google, but, that's the reason why you are using client-only paths, in most of the cases you don't want to index those pages.
So I noticed when I ran my react app's production build's login screen from create-react-app that all of the source code for the app was available within the static/js folder. Basically, the code doesn't look any different from the code in my ide, on the production build.
I am wondering if there is a way to hide this behind a login screen? So that a user can't directly access these files unless the login is successful. I have looked around and was unable to find anything of use.
The js files from the production build should be minimized which would look a lot different than in your IDE. I assume what looks "the same" is looking at the source using developer tools. The solution for that is to not deploy the source map files (*.js.map). Those are the files that allow developer tools to transform the minimized code back to its original look.
Removing source maps makes it difficult for someone to learn from the code easily, but if there is sufficient motivation to do so, it can still certainly be reverse-engineered. There are also some parts that wouldn't be obfuscated much at all such as the URLs for API calls which would then give someone a lot more information to use as the basis for hacking attempts.
If you need to prevent seeing any version of the source for people that are not logged in, I would recommend building your app as two apps -- one that just contains the login portion and one with the rest. Code-splitting within one app won't do the trick (at least not without using a solution that is quite a bit more complicated to manage than the two-app option), because it just makes the download process lazy and it is still pretty easy for someone to determine what the other files are and download them. However, even splitting this into two apps only helps if you host the second app differently. This will require server-side protection that only serves the JavaScript files for the second app for a user that is logged in. This means either using a different sub-domain for the second app or at least a different directory on the server that has those protections baked in. How you would implement that protection depends on the details of your authentication approach and the technology stack being used on the server. Most likely, it means using a cookie set by the login process and then having the JS files for the second app served up by something that verifies the cookie before allowing the JS files to be served to the browser.
To overcome displaying your source code in production's build, try to build your app with
GENERATE_SOURCEMAP=false npm run build
I'm working for a company right now and for their whole website they use Cache (language) to 'spit' out HTML onto the page to be rendered then JavaScript and jQuery (and CSS) is used for other things from there.
I've learned React and have been writing Components that I want to use and learned react-router to do my client side routing for me.
I don't know how to integrate the routing part of the webpage (the code essentially) that has been already created with Cache and JavaScript with the new React pages and react-router
The company has no routing whatsoever right now. It is a bunch of iframes like a tree type structure with links so I really need to get it converted to a routing sort of setup.
Sorry It's so long, but now is my question:
Would I use a Node.js webserver and Express.js for the routing for the already build Cache/JavaScrip pages and then once I get that taken care of start using react-router from there to take care of all the new React Components?
Any help is appreciated
Take a look at EWD 3:
https://community.intersystems.com/post/announcing-ewd-3-integrating-javascript-nodejs-and-cache-communities
Also look for the postings in this forum on EWD 3 and React.js (and React Native):
https://groups.google.com/forum/#!forum/enterprise-web-developer-community