[Lee KlausParticipant]

Yes, I do understand that… It’s unclear to me as to exactly what some of the UI component providers do to avoid having problems. Ie., Veutify is a good example – provides a lot of UI components, but will still work on the server side.

Perhaps the architecture of what they have done is somewhat different, given that they don’t have the history that you have with your library…

It’s just a thought – not a huge deal, but…. wanted to check.

[Lee KlausParticipant]

Yes, certainly…

NUXT is essentially a framework that compliments Vue in order to build a “universal application”. More details can be found here: https://nuxtjs.org/

It has gained some level of traction because:

1) It renders pages the first time through on the server (not the client), and what that means is that the results returned to the client look more like “the real page”, not just links to javascript. This is primarily important because search engines like google are then more likely to accurately index your page with “real content”, not just javascript.

2) In theory, the page render can happen quicker as well, since you don’t have to wait for a bunch of javascript to download and run prior to showing some “real” content to the user.

And lastly, NUXT provides a bit of an application configuration framework where development of a more complex application is somewhat simplified through well-organized directory structures, a solid build process with webpack, etc.

So what does this mean?

1. It means that a any Vue component has to be cautious around exactly what it does during the render. If, for example, the rendering directly references the window object of a browser, it will fail on the server when NodeJS does a “server-side” render. That part of it starts to get over my head, but a lot of people are starting to write components so that they won’t error out when rendering on the server (even if perhaps the “render” is not “pretty”, etc.

To work with JQ components and NUXT, here’s what you currently have to do:

1. When using a component, wrap the component in <no-ssr> tags in the the page that you are constructing. This tells NUXT not to render that component on the server side.
2. When requiring the component, you have to bind to the component on the client side, and intentionally avoid binding on the server where it will cause problems. Here’s how I deal with that:

<script>
let JqxButton = null;
let JqxSplitter = null;
let JqxTree = null;
let JqxMenu = null;

if (process.client) {
JqxButton = require(“jqwidgets-scripts/jqwidgets-vue/vue_jqxbuttons.vue”)
.default;
JqxSplitter = require(“jqwidgets-scripts/jqwidgets-vue/vue_jqxsplitter.vue”)
.default;
JqxTree = require(“jqwidgets-scripts/jqwidgets-vue/vue_jqxtree.vue”)
.default;
JqxMenu = require(“jqwidgets-scripts/jqwidgets-vue/vue_jqxmenu.vue”)
.default;
}

export default {
components: {
JqxButton,
JqxSplitter,
JqxTree,
JqxMenu
}, …

Hopefully this helps – I know it can get complicated quickly…

Lee

[Lee KlausParticipant]

Thanks for this additional demo. This will be very helpful, I’m sure.

I’d like to ask one clarifying question on the tree component: When I bind the tree source to a data structure that represents the tree, the data structure of the tree is not automatically updated when a node is added to that tree via the UI – is that an accurate statement?

Thanks… Lee

[Lee KlausParticipant]

Sounds good. I’ll take that approach. Thanks for the prompt reply!

[Author]

Posts