I'm making an express app, and I have two /get routes: one executes a function that does res.render("file.ejs") that has a css stylesheet in it and everything works, and the other executes an async function that does things before rendering (the fact one is async is the only difference I can spot; I even made them render the same file and the result was the same: the async one didn't load). There is no error in the console on the website or server side, the page just keeps loading (it's not just the css not loading, the contents of the page are also missing)
I know all files are referenced correctly because when I remove the stylesheet from the ejs file the page loads its contents.
Is there anything to that async being there or should I look for the error somewhere else?
I am pretty new to this, but Thanks in advance.
Related
I'm using Next.js version 12.0.4 on a new project, having used Next.js version 10 on a prior one.
Has something changed with Static Site Rendering at build time? It's rendering all my output pages when I do an npm run build (which in turn executes "next build and next export") with html files that include a ton of .js files and no native text "content" which I'd expect.
That is, the output doesn't have any of the standard HTML <h1>, <h2> etc. in it, just a bunch of javascript for the client to hydrate.
Prior versions of Next.js (or perhaps it was my configuration?) seemed to render pure, finalized HTML just fine.
I'm trying to render a simple About page (no dynamic routes, no dynamic props for this route) and, while it properly renders a page in the "/about/index.html" output location, that page has a bunch of .js files and a JSON payload. That page does indeed display properly, but I'd really like the output in the "out" directory to be actual .html files with HTML pre-rendered, for SEO and other reasons.
In my next.config.js, I've specified:
module.exports = {
exportPathMap: function () {
return {
"/": { page: "/" },
"/about": { page: "/about" },
};
},
};
I've also specified getStaticProps on the about page conponent (about.tsx). (I'm using typescript if that matters.)
The rendered /about/index.html file has a ton of .js includes and no real HTML "content".
Have I missed a configuration setting? What can I do to make it render pure HTML where I'd like?
AHA! Ok, so this error was of course a coding error on my side.
In _app.tsx, I had a wrapper for Authentication that I had written. By (bad) design, it was deliberately NOT rendering children for it if the user wasn't authenticated. Therefore, the pre-renderer wouldn't render the "regular" html elements, because the pre-renderer of course does not sign in.
If this same problem happens to you, make sure you're not wrapping all views up in some provider element which conditionally renders children.
i'm trying to improve speed of my website. i'm using PageSpeed Insights to check my site performance and it was telling me to remove render blocking java script and css. so i did it and know its causing problem in my website design. so what should i do to remove rendering blocking without causing problem in my website design.
Render Blocking CSS
Render blocking CSS will always show on Google Page Speed Insights if you are using external resources for your CSS.
What you need to do is to inline all of your 'above the fold' styles in <style></style> tags in the head of your web page.
I will warn you, this is NOT easy and plugins that claim to do this often do not work, it requires effort.
To explain what is happening:-
A user navigates to your site and the HTML starts downloading.
As the HTML downloads the browser is trying to work out how to render that HTML correctly and it expects styling on those elements.
Once the HTML has downloaded if it hasn't found styles for the elements that appear above the fold (the initial part of the visible page) then it cannot render anything yet.
The browser looks for your style sheets and once they have downloaded it can render the page.
Point 4. is the render blocking as those resources are stopping the page from rendering the initial view.
To achieve this you need to work out every element that displays without scrolling the page and then find all the styles associated with those elements and inline them.
Render Blocking JS
This one is simpler to fix.
If you are able to use the async attribute on your external JS then use that.
However be warned that in a lot of cases this will break your site if you have not designed for it in the first place.
This is because async will download and execute your JS files as fast as possible. If a script requires another script to function (i.e. you are using jQuery) then if it loads before the other script it will throw an error. (i.e. your main.js file uses jQuery but downloads before it. You call $('#element') and you get a $ is undefined error as jQuery is not downloaded yet.)
The better tag to use if you do not have the knowledge required to implement async without error is to use the defer attribute instead.
This will not start downloading the script until the HTML has finished parsing. However it will still download and execute scripts in the order specified in the HTML.
Add async in the script tag and put the css and js in the last of the page
Load Order Issues
I am having trouble making Meteor load my JavaScript after my HTML file fully loads when I go to localhost:3000. The problem is that my JavaScript keeps loading before my HTML file, and makes the page look unloaded when I use stuff like alert(); or prompt();. I've tried a lot of solutions such as naming my JavaScript file as main.js and putting my HTML file in a deeper directory and using <script> tags. I have also read the documentation concerning this: http://docs.meteor.com/#/full/structuringyourapp Solutions I've tired based off the documentation such as putting files in client/lib , client/compatibility , and lib have proven to no avail. I also tired Meteor.startupand I placed the file for it in the client folder. (The code inside it):
Meteor.startup( function () {
$.get("client/lib/testproject.html")
$.getScript("client/testproject.js");
});
The above sort of solved my problem, but it loaded the JavaScript file two times. The first time was before the HTML loaded and the second time was after the HTML loaded. I don't know a way to prevent the first JS load from happening when using Meteor.startup, so any solutions for that are also appreciated.
The JavaScript file's code I am referring to is simple. (In it's entirety):
prompt("Hello World!");
myList = ["apples", "oranges", "bananas"];
myList.forEach(function(value, index) {
alert('I have ' + value + ' for dinner.');
});
Summary
To summarize my problem:
My Problem:
Go to localhost
JavaScript loads first
HTML loads second
What I Need:
Go to localhost
HTML loads first
JavaScript loads second
The Question: How can I make my JavaScript load only after when my HTML is loaded? And how can I restructure my folder, file-names, and/or code to make it behave as I want it to in this case?
Since the code posted is extremely simple to reproduce I kindly ask that you
run your own solution with a setup similar to what I have and not something that uses a million packages since that is unnecessary for my case, on Meteor, before responding to this.
I'm on Meteor 1.1.0.2
Here is a link to my folder structure with included HTML code along with filenames I used: http://i.imgur.com/24z6bXF.png
I think you missed a decisive information : you should wrap your Javascript code into a Template.yourTemplate.rendered=function () {} function.
That is the meteor way to ensure that your related html code is properly rendered first.
First of all, Meteor will always repackage your files and load them automatically in a specific order (Meteor structuring your app). First files in client/compatibility then client/lib and then the others JS files.
You should also rewrite your code so it does not get executed immediately at load time, like wrapping everything in a function. And then, you should call this code when the DOM is loaded, which does not necessarily mean in Meteor.startup but also in onRendered callbacks in your templates.
I still can't quite get Meteor's load order fully under control. I use a lot of 3rd-party scripts when using Bootstrap templates with animations and a lot of these scripts break because they are created with the traditional load order in mind for DOM nodes.
Meteor does not follow this traditional load order, so a lot of times DOM nodes aren't ready when the scripts fire.
I made a simple Meteor app that console logs a message each time a script inside of a particular folder or template.rendered callback is loaded.
https://github.com/fuzzybabybunny/meteor-load-order-test
You can see it deployed here (open up Chrome Console)
http://load-order-test.meteor.com/
There are a few strange things going on.
main.js and main.html are actually loaded very soon, counter to what the documentation says: http://docs.meteor.com/#/full/structuringyourapp
all the DOM nodes are actually created earlier than expected
with six templates that still have yet to have their .rendered() callbacks fired, the max number of DOM nodes has already been reached. We should expect more DOM nodes to be added with each .rendered() callback being fired.
Can someone help explain why I'm seeing these strange things?
Also, is there a surefire way to only run a script once all DOM nodes have been created? Currently it seems like using jQuery to append <script> tags somewhere on the DOM inside of Template.Layout.rendered would be the most foolproof.
Template.Layout.rendered = function(){
console.log('layout template rendered and the number of DOM nodes is ' + document.getElementsByTagName('*').length);
$('head').append('<script src="/javascript/domCompleteScript.js"></script>');
};
Per the documentation, slightly further down the page:
client/lib/ # code for the client to be loaded first
This folder is for compatibility JavaScript libraries that rely on variables declared with var at the top level being exported as globals. Files in this directory are executed without being wrapped in a new variable scope. These files are executed before other client-side JavaScript files.
I would try putting the 3rd-party scripts into the following places, just to see what works best:
client/lib
client/compatibility
lib
We have a requirement to provide skinning capabilities to an ASP.NET MVC3 app.
My approach so far has been to tackle this with a cookie and child actions for the css files:
Client links to our app using a URL like www.ourapp.com/as/www.clientapp.com/then-go-to/path/in/ourapp.
The above url is routed to an action method that writes a cookie named "skin" with value "www.clientapp.com" and then redirects to /path/in/ourapp.
Our layout (masterpage) has an #Html.Action in the <head> section where the css files are to be rendered.
The child action inspects the cookie and creates a viewmodel that will tell the partial view which <link> tags to render.
The css file structure is based on the cookie value. So our css content might look like this:
/content
/www.clientapp.com
/style1.css
/style1.css
/www.client2app.com
/style1.css
/style2.css
I am open to hearing better patterns / alternatives to the above for applying skins to the layout. However this isn't the reason for my question.
There is currently a problem with this approach when the css files are not present in the filesystem. The request causes IIS to return a 404. We override the 404 page with a custom page (not using the same layout that has the #Html.Action in the <head>). This causes IIS to do some additional processing which is not necessary (for example partials & child actions to render sign-in/sign out links, horizontal nav, etc, on the 404 page's layout).
The way I see it there are 2 ways to solve this:
In the child action that configures the css, check to make sure the files exist on disk before telling the viewmodel that they should be rendered. Pro with this approach is that it should be fairly easy. Cons are that to unit test it, would have to wrap file I/O in a service that can be injected. Also the app will be deployed to Azure. I think Azure can read the filesystem (which is what would be needed), but not write to it.
Somehow prevent a 404 from being returned for css files. To do this, would we have to implement logic in global.asax Application_Error? Or is there another way to prevent missing CSS files from triggering a 404 response?
Which approach is correct? Or is there another that I'm not considering?
Update
We ended up solving this in the custom 404 error page like so:
[ActionName("not-found")]
public virtual ActionResult NotFound()
{
// do not return 404 for missing css files
if (Request.RawUrl.EndsWith(".css", StringComparison.OrdinalIgnoreCase))
{
Response.StatusCode = 404;
return new EmptyResult();
}
return View();
}
One option would be to not override 404 errors for CSS requests.
For missing CSS files, return the 404 status, but leave the body empty. The body doesn't matter with a CSS file, since a human doesn't see it, and all the browser cares about is the status.