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.
Related
So I'm finding it difficult to see the benefits of doing SSR for dynamic paths in NextJs when I can just just pre-render a few static paths, and use fallback=true to cover my bases on most pages.
Say I have an eCommerce site with 1 million product detail pages, but I only want to pre-render featured products on the home page(most clicked). If I set fallback to true in getStaticPaths, then the getStaticProps function runs every time a non featured product page is requested.
So what's the advantage of using SSR when I can just have a fallback that queries the database every time a non pre-rendered page is called?
Note: I saw a similar question on Stack Overflow, and the answer was that web-crawlers see only the fallback state of your react Component that you set for non pre-rendered pages (so the source code would only read <p>Loading...</p> or something like that, vs the SSR page which would load all your data for the product directly as the source code. But this doesn't seem to be true in my app.
Thanks for any help.
TLDR: [In NextJs..] Why can't I just use SSG for dynamic paths, with fallback=true in getStaticPaths, instead of SSR?
THANKS ALL
I tried reading the NextJs docs and couldn't find an explanation for the cons of using fallback=true in getStaticPaths
From next.js docs:
By default, Next.js pre-renders every page. This means that Next.js
generates HTML for each page in advance, instead of having it all done
by client-side JavaScript.
Two Forms of Pre-rendering
Next.js has two forms of pre-rendering: Static Generation and
Server-side Rendering. The difference is in when it generates the HTML
for a page.
Static Generation is the pre-rendering method that generates the HTML
at build time. The pre-rendered HTML is then reused on each request.
Server-side Rendering is the pre-rendering method that generates the
HTML on each request.
I put those definitions to clarify the terms in next.js. I believe your question is regarding fallback:true versus generating HTML on each request (or building page runtime vs build time). I think this note you shared is not correct
Note: I saw a similar question on Stack Overflow, and the answer was
that web-crawlers see only the fallback state of your react Component
that you set for non pre-rendered pages (so the source code would only
read Loading... or something like that, vs the SSR page which
would load all your data for the product directly as the source code.
But this doesn't seem to be true in my app.
In each case the populated page is seen by the crawlers.
Using getStaticPath in your e-commerce example is the usage of caching. those pages for popular products are already built and inside next build folder you can see them if you build your app locally. But in large applications, those static assets are stored in CDN, and whenever the server gets a request response will be in no time. so customer will have a better user experience so which will eventually affect the profit of the ecommerce site.
I think the clearest example would be thinking about a blogging website like Medium. The most popular blogs will be pre-generated since the content of the blogs do not change that often. Medium will use CDN's from different parts of the world, so user all around the world will have faster access to blogs.
Hitting databases is a very expensive operation. The more load you have on the database harder to maintain the availability, scalability, and reliability of your application.
Also, you might have a better internet connection, you use high end clients so you might access any data faster but you have to think about all people around the world who try to access data with low-quality clients or internet connections.
I am new to the Nuxt development platform, having worked mostly in Vue(v2).
Having delved into the docs and experimenting locally for a bit there are a few things I still require clarity on:
In static generation mode, does each page its get its own Vue app instance? That is, every pre-rendered page that is requested from the server behave as an SPA on the client.
If #1 is true, does every page, and in effect, every app run isolated from all other pages and apps? No shared state?
When using Vuex in SSG mode, does each page get its own Vuex store that is inflated with an initial state while rendering the page on the server? And, does this state get passed down to the client?
This store is destroyed on navigating to a different page (or even refreshing the current page), to be replaced by a new one right?
In SSG, every page is rendered ahead of time but at the end, will be hydrated and hence become an SPA. Nuxt is basically Vue on steroids but it's still Vue.
Not sure what you call isolated here, you can totally pass props, use emit etc... Meanwhile yeah, if you do have pages, they are not all loaded at the same time, there is code splitting + lazy loading + prefetching. Some info can be found here.
You can have namespaced modules out of the box when using Vuex with Nuxt. You do have nuxtServerInit to pre-populate the store yes. You could give a read to the Nuxt lifecycle btw. But you don't have a Vuex module by page out of the box, there is no real usage for this IMO. And yeah, you'll get your Vuex store on the client of course.
If you navigate to a different path with a <a></a> tag, you will nuke your SPA yeah. If you're using <nuxt-link></nuxt-link>, you'll stay in the SPA since the Vue router will make the "navigation". But yeah, if you type a path directly into the url and press Enter or refresh the page with F5, your entire SPA will be nuked and everything will be replaced from the ground up.
I've spoken at the latest Nuxt-nation, the quality is not amazing (sorry for this) but you could maybe get some interesting things out of it.
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.
I have created a dashboard in Keen and I want to use the same dashboard in my web application. Is there any way a complete dashboard can be embedded in another application?
Iframe won't work due to crossorigin restriction. Using javascript to create widgets of a dashboard is a solution but I wanted to skip the coding part of it. Reason for this is because if my client wants to update the dashboard then he can do so by simply updating it on keen and new build should not be required for such thing.
I work at Keen and you're correct that the iframe won’t work, because of the security changes introduced to the browsers to stop clickjacking attacks.
In the first iteration of “embed html” we used a static version of the properties used to store your json (which contains info about the charts to render and the names of saved queries to use).
We're working on deploying the updated version of the dashboard-viewer - which supports dynamic loading of the current state of the dashboard.
This should solve the issue you're referencing. If you would like to submit a ticket on our website would could provide a time as it get's closer to launch. Just reference this url.
https://responsivedesign.is/articles/xframe-options/
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
I am starting to play around in React and I noticed that the simple app I am making is all in JS. My html page is only an empty body tag!
So I had a few questions because I am new to this framework.
Is my whole app supposed to be essentially all JS?
If it's not supposed to be all JS, when do I decide that something belongs in my html file vs creating it as a react component in JS?
What are the benefits / disadvantages that my html is in all JS?
Am I supposed to set up my server to compile the JS to html to serve html re: Server Side Rendering to maximize performance benefits?
React brings a new way of seeing things: components.
There are two approaches when using React:
AMD (Asynchronous Module Definition): your javascript files are loaded under demand; https://en.wikipedia.org/wiki/Asynchronous_module_definition and in http://requirejs.org/docs/whyamd.html
CommonJS: in this case your app is bundled into only one file (or a few 'chunck' files) - it seems that people have been preferred this way because the app is loaded only one time and it goes to the server only for loading and writing data (i.e. JSON); it helps in reducing charges over the server;
The page is really an empty body tag.... hehe
But with some considerations:
Please take a look at React-Router (or even Angular Route if you use AngularJS):
To move from the current 'page' (view) to a new page, the browser's URL is 'pushed' (changed) without going to the server and the entire new page is mounted according to that URL. This is made by React-Router or Angular Route.
Yes, you are supposed to make your server to output html: you can search for Isommorphic Javascript if you want your client html to be mounted dynamically (useful when you need search engines like Google to scan your page) More info at: http://isomorphic.net/ and this can help you: https://strongloop.com/strongblog/node-js-react-isomorphic-javascript-why-it-matters/
I know there is a lot of new technologies to study, but it's worth...
A little tip I can give you is looking for "Flux". It's a design pattern that helps structuring your application better, that allows you to scale and grow it.
You can take a look at webpack and babel too. Great stuff!
Hope this helps you.