A while back, I looked into a solution for the "flash of unstyled content" when using Dojo and Dojo themes. Someone suggested to combine everything by creating a build, and it'll reduce the load/parse time and remove the need to use preloader overlays, etc.
However, it seems like Dojo is severely lacking in straightforward, "real world" useage examples and tutorials for a lot of its functionality, this especially. A lot of the resources tell you how to set up a build, but not how to implement it.
Let's say I have this in "pageinit.js":
require([
'dojo/parser',
'dojo/dom',
'dojo/dom-class',
//etc...
'dijit/form/ValidationTextBox',
'dijit/form/CheckBox',
// etc...
// Dom Ready call
'dojo/domReady!']
function(
Parser,
Dom,
Class,
// etc...){
// do stuff with parser, dijits, so on.
}
)
Some of the require calls were removed for brevity, but there's a handful of dom requires, style classes, some dijits, etc. When this page loads, there's the flash of unstyled content and then it's fine.
Using the Dojo Web Builder, I selected the modules I'm using, and ran it. It downloaded a zip with a lot of files under it, including a new dojo.js and custom_layer.js.
So my question is now, how do I use these new combined and minified files in place of my "non-build" version? What do I require? Or do I?
So confused...
First, let's understand how the AMD(require/define) API works.
require([
'dojo/parser',
'dojo/dom',
'dojo/dom-class'
], function(parser, dom, domClass){
});
This is going to call the require function, specifying that I need three modules in order to do some work. require will get each module. If will determine if the module has been loaded. If it hasn't it will asynchronously get the file, and load the module into the javascript runtime. Once require has retrieved all of your required modules, it will execute your callback (the function) passing the modules as arguments to the function.
Next, let's understand the build. The dojo build does exactly what you describe. It will compress a bunch of the individual files into a single file. this will make the page load quicker and prevent that 'flash' that you describe.
Finally, putting it all together, you should include the custom_layer.js file along with the dojo.js file.
<script type="text/javascript" src="path/to/dojo/dojo.js" />
<script type="text/javascript" src="path/to/custom_layer.js" />
The web browser will load these two files and evaluate the code. Instead of lazily loading each module in it's own file, the module will already be loaded because it was defined in the custom_layer.js.
So, the answer to your final question is that you should NOT change any of your code based on the specific version of code (source vs custom build) that you are using. Using the AMD api, it should just work.
Not sure if it's best practice or not, but I was seeing the flash of unstyled content when I first started (a few days ago), and saw several examples somewhere that takes care of by just hiding the <body>. Parse will unhide it when it's ready to show something.
<body style="visibility: hidden;">
Related
Currently I'm developing a website using the following stack:
vue.js
#vue/server-renderer
vite
tailwind CSS
SSG was chosen as the rendering mode.
Tailwind, as described in the documentation, allows you to specify directories and file extensions (content property) , in which he will try to find the classes, in order to leave only those that are actually used in the project.
As a result, the 'main.css' file is formed, in which only those classes that are used remain.
Next, I just take this file and include it in every page that was rendered during the build phase of the project.
This results in:
index.html - main.css
about.html - main.css
blog.html - main.css
It turns out that main.css file may contain classes that are needed only for one of the pages and are not needed for others.
I would like to implement the following:
Take main.css which turned out
Render a page, for examle about.html
take only those styles that are needed for about.html page from the main.css file
create a new about.css file
link the resulting about.css styles to about.html
I’ve already tried to implement this using an awesome PurgeCSS tool as following:
render page content usind #vue/server-renderer's renderToString() method;
Pass an resulting css and html sources to PurgeCSS
here is an example
But there are too many corner cases around this solution, such as:
Dynamic classes which can be added to the html on the client side
Some components may be missing in rendered html and their content will be added later (for example, v-if directive was used on the component)
A few takeaways:
PurgeCSS is not needed anymore since Tailwind v2 (the latest being v3.x)
as far as I know, you cannot have code-splitting with Tailwind, not that it matters anyway since it will still perform okay with further optmizations
the classes that will be generated, will be only once for the whole app (hence no need to have a bg-red-500 for index or about page, both are referencing the same unique declaration)
if you want to have SSR/SSG, I recommend the usage of Nuxt (in it's v3 if you're using Vue3 or plan to have anything long-term)
dynamic classes are not possible with Tailwind, you can create things like bg-[#ccc] but it goes on the opposite side of what Tailwind is achieving and should be used exceptionally
for Tailwind's content, still the defaults on this page, section Configure your template paths, no need to do anything crazy or complicated
if you want to have some scoped/local style, style to using style scoped, you can still use Tailwind inside of those tags tho
if you want to write vanilla CSS into dedicated CSS files like index, about, blog etc, then Tailwind is probably not the best approach because this is not how it is supposed to work
stay simple, the performance will still be amazing. Only focus on not having too many screens, colors etc that you're not using
you could run some bundle size tests to see if the CSS is taking a huge chunk in terms of size. Will probably not, but if it still is: you can then start making complex configurations
JS will be far harder to reduce and be more impactful regarding the performance (because of how a browser works with it: parsing, executing is indeed blocking the main thread)
I have a very, very simple set of Vue components that all work. These are a simple addition on top of an existing C# app.
At the moment, these are .html files (brought into the app inside <script> tags) and .js files loaded by reference.
These all work, are very light weight, and I love it.
Now I want to compile the HTML for each component into a Vue render function, and the .js into one minified .js file.
The .js to .min.js is pretty standard, but I cannot figure out how to get the HTML to compile into the Vue render function. Everything I've found involves a LOT of overhead and running a web server which seems a massive overkill for an html->script transform, and I don't need a full web application spun up. I only need my existing, simple templates transformed to something more friendly for production than my long-form html templates getting dumped to the page.
I'm not entirely opposed to turning the .html+.js into .vue files, but just doing that doesn't seem to overcome my issue.
I cannot figure out how to get the HTML to compile into the Vue render function
To generate a render function from a Vue template string (e.g., read from an HTML file), you could use vue-template-compiler like this:
const compiler = require('vue-template-compiler')
const output = compiler.compile('<div>{{msg}}</div>')
console.log(output) // => { render: "with(this){return _c('div',[_v(_s(msg))])}" }
Everything I've found involves a LOT of overhead and running a web server which seems a massive overkill for an html->script transform
The "web server" you mention is provided by Webpack CLI, and is intended to faciliate development. You don't need to use the dev server. The article indeed describes several steps in manually setting up a project to build Vue single-file-components, but a simpler method is to use Vue CLI to automatically scaffold such a project.
I'm trying to understand the usage and limitations of server side rendering with vuejs when using aspnet core.
I used this starter kit for aspnet core and vuejs to setup a simple vue site, which is running based on the code here: https://github.com/selaromdotnet/aspnet-vue-ssr-test/tree/master
I then modified the project to update the aspnet-prerendering and added vue-server-renderer, compiling a hodgepodge of sources to cobble together this update: https://github.com/selaromdotnet/aspnet-vue-ssr-test/tree/ssr
If I run this project, the site appears to load fine, and if I turn off the javascript in the browser, I can see that it does appear that the server-side rendering executed and populated the html result:
however, because JavaScript is disabled, the content isn't moved into the dom as it looks like it is trying to...
My understanding of server-side rendering is that it would populate the html entirely and serve a completed page to the user, so that even if JS was disabled, they'd at least be able to see the page (specifically for SEO purposes). Am I incorrect?
Now I believe modern search engines will execute simple scripts like this to get the content, but I still don't want a blank page rendered if js is disabled...
Is this a limitation of server-side rendering, or perhaps specifically ssr with vue and/or aspnet core?
or am I just missing a step somewhere?
Edit: more information
I looked at the source code for what I believe is the method that prerenders the section here: https://github.com/aspnet/JavaScriptServices/blob/dev/src/Microsoft.AspNetCore.SpaServices/Prerendering/PrerenderTagHelper.cs
The line
output.Content.SetHtmlContent(result.Html);
has a null value for result.Html. However, when I manually edit this value to put a test value, it also doesn't render to the output html, and the app div tag is still empty...
If I'm doing something wrong to populate the result.Html value with the expected output, that's one thing, and I would appreciate some help in doing that, especially since the output html appears to be found, since it's in the script that immediately follows...
However, even if I were to populate it, it appears it's being skipped, as evidenced by me manually changing the value. is this a bug in the code or am I doing somethigng wrong, or perhaps both?
As you correctly noticed, for your project, result.Html inside the tag helper is null. So that line cannot be the location where the output is being generated. Since the HTML output from your prerendering script also does not include a script tag, it is clear that something has to generate that. The only other line that could possible do this is the following from the PrerenderTagHelper:
output.PostElement.SetHtmlContent($"<script>{globalsScript}</script>");
That would fit the observed output, so we should figure out where the globalsScript comes from.
If you look at the PrerenderTagHelper implementation, you can see that it will call Prerenderer.RenderToString which returns a RenderToStringResult. This result object is deserialized from JSON after calling your Node script.
So there are two properties of interest here: Html, and Globals. The former is responsible for containing the HTML output that finally gets rendered inside the tag helper. The latter is a JSON object containing additional global variables that should be set for the client side. These are what will be rendered inside that script tag.
If you look at the rendered HTML from your project, you can see that there are two globals: window.html and window.__INITIAL_STATE__. So these two are set somewhere in your code, although html shouldn’t be a global.
The culprit is the renderOnServer.js file:
vue_renderer.renderToString(context, (err, _html) => {
if (err) { reject(err.message) }
resolve({
globals: {
html: _html,
__INITIAL_STATE__: context.state
}
})
})
As you can see, this will resolve the result containing just a globals object with both html and __INITIAL_STATE__ properties. That’s what gets rendered inside of the script tag.
But what you want to do instead is have html not as part of globals but on the layer above, so that it gets deserialized into the RenderToStringResult.Html property:
resolve({
html: _html,
globals: {
__INITIAL_STATE__: context.state
}
})
If you do it like that, your project will properly perform server-side rendering, without requiring JavaScript for the initial view.
I'm exploring Electron and I've run into a roadblock. I can't figure out how to load the Dojo Toolkit and use it in Electron.
For example, here is the simple "Hello World" for Dojo:
<!DOCTYPE html>
<html>
<head>
<title>Tutorial: Hello Dojo!</title>
</head>
<body>
<h1 id="greeting">Hello</h1>
<!-- load Dojo -->
<script src="//ajax.googleapis.com/ajax/libs/dojo/1.10.4/dojo/dojo.js"
data-dojo-config="async: true"></script>
<script>
require([
'dojo/dom',
'dojo/dom-construct'
], function (dom, domConstruct) {
var greetingNode = dom.byId('greeting');
domConstruct.place('<em> Dojo!</em>', greetingNode);
});
</script>
</body>
</html>
That works fine in a browser, but doesn't work at all in Electron. After a couple hours of googling and trying 50 different experiments I've gotten nowhere.
Can someone please enlighten me?
While you can disable node-integration as Shwany said, I believe that will effectively render the ipc modules useless, which will probably pose undesirable limitations since you won't be able to communicate between the main and renderer processes.
However, it is possible, with a bit of finagling, to get Dojo to play nice with Electron. There are only a couple of things you need to do in your entry page.
Firstly, force the host-node has feature to false. This can be done by setting it in dojoConfig.has, e.g.:
var dojoConfig = {
async: true,
has: {
'host-node': false
}
}
Secondly, as Shwany pointed out, Dojo is going to see the already-existing require, so we need to move that out before loading Dojo:
// Move Electron's require out before loading Dojo
window.electronRequire = require;
delete window.require;
After loading dojo.js, you can move Dojo's require elsewhere and move Electron's back, if you wish. Whether you want to do this may depend on how you intend to code the client side of your application. Ostensibly, Dojo's global require is never needed, since you can request a context-sensitive require in any defined module via the 'require' module ID.
If you want to see a scaffolded Electron application incorporating Dojo, I created a boilerplate a few weeks ago (though be advised it's currently relying on a fork of electron-packager). If you want to see an example of a more full-blown Electron/Dojo application, I wrote a music player called Nukebox a couple of months ago which uses Dojo and dgrid (though its scaffolding is a bit different than the newer boilerplate).
I have your test code working in Electron.
First, I assume you are trying to load dojo.js from the web. //ajax.googleapis... etc will probably attempt to pull the file from the file system. I added http: to the front of it. That allowed me to open a .html file in the browser and work. I am not sure if that was an oversight or not.
Secondly, because the browser-window has node-integration on by default, 'require' is already defined and it does not understand what you are passing to it because it expects a path not an array. If you construct your browser window with node-integration turned off it should work:
app.on('ready', function() {
mainWindow = new BrowserWindow({width: 800, height: 600, "node-integration": false});
mainWindow.loadUrl('file://' + __dirname + '/index.html');
mainWindow.openDevTools();
mainWindow.on('closed', function() {
mainWindow = null;
});
});
Note the "node-integration": false. This may cause additional issues if you want to use node integrations in your app. However, your code should work.
I'm using the following html to load dojo from Google's hosting.
<script src="http://www.google.com/jsapi"></script>
<script type="text/javascript">google.load("dojo", "1.1.1");</script>
<script type="text/javascript">
dojo.require("dojox.gfx");
...
This errors out on the requre line with an error like dojox.gfx is undefined. Is there a way to make this work, or does Google not support the dojox extensions?
Alternatively, is there another common host I can use for standard dojo releases?
Differently from when you reference the .js files directly from the <script> tag (note that google js api also supports this, see here), google.load is not synchronous. This means that when your code reach google.load, it will not wait for dojo to be fully loaded to keep parsing; it will go straight to your dojo.require line, and it will fail there because the dojo object will be undefined.
The solution (if you don't want to use use the direct <script> tag), is to enclose all your code that references dojo in a start function, and set it will as a callback, by doing:
google.load("dojo", "1.1.1", {callback: start});
function start() {
dojo.require("dojox.gfx");
...
}
or
google.setOnLoadCallback(start);
google.load("dojo", "1.1.1");
function start() {
dojo.require("dojox.gfx");
...
}
A better question is - why would you want to? If you are developing on your localhost then just use a relative path, if you're developing on an internet facing server - stick the dojo files on that.
Also - make sure you're not falling foul of the same origin policy
I believe that google becomes the namespace for your imported libraries. Try: google.dojo.require.
Oh! And as pointed out below, don't forget to use google.setOnLoadCallback instead of calling your function directly.
dojox is practically unmaintained, and will be taken out from dojo-2. There are major problems with most widgets in dojox, there is only a few good.
IMHO dojo should be self-hosted, because there are always things what you need to overwrite - for example, you need some fix in this dojox.gfx.