Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In my own experience, I like programmatic coding. To name a few benefits at here:
Better performance: no need to parse.
No switch between html and javascript: no html, everything in code(use css to control layout.)
Easy to dynamically change the content.
Easy to be read and be maintained.
But, it seams a lot of users at here using declarative coding. my question is : what's the benefit to use declarative coding? Which one is dojo gurus' favorite?
Like fransisco said, you can seperate your code easier. I mean, if you instantiate all your widgets in your JavaScript code, your JavaScript will become pretty large and your HTML will usually be small (only contains "container" nodes which you use to place widgets in).
Better performance: I have to agree with you that it indeed lowers the performance since you have to parse your entire page, but you can optimize that by disabling parseOnLoad and by only parsing the DOM nodes you actually need. At the company I work for we did that by placing all Dojo widget markup inside a <div> with a certain classname. Then in our JavaScript code we do something like:
query(".containsDojo").forEach(node) {
parser.parse(node);
});
No switch between HTML and JS: The switch between HTML and JS makes it easier to understand your code and to have a context. For example, if you need to modify widget A by widget B that's placed on a page called C.html. Then it's easy to look for your widget A since you know on what page it is and where it's located (top, bottom, ...). If you put everything in your JavaScript file, you will have a hard time managing your code since you don't know in what context the widget is initialized. You will have to look through your entire JavaScript code because the widget can be initialized at any point in your code.
Easy to dynamically change the content: If you need dynamic content I usually create some kind of widget myself and put the JavaScript logic there so my "main" JavaScript and HTML code still look clean. You can always use the dijit/registry module to change certain things in your content.
Easy to read and be maintained: I totally disagree with that, similar to what I said in my previous paragraph about the switch between HTML and JavaScript. I mean, what's the difference between a dijit/form/TextBox and a normal HTML input-field? Not much, they're both UI items. Yet, if I follow your thoughts I would put the TextBox somewhere in the JavaScript code and the normal HTML input field inside your HTML. The HTML not only provides you a context, but also centralizes all UI elements.
Related
Not really a code problem more a discussion/brainstroming-post.
I would like to build some light CMS in Vue/Nuxt, which will output a static website in the end.
So I thought about going for one Nuxt-page (does not have to be a Nuxt-page necessarily) containing all the CMS-related stuff and handle the actual website inside a nuxt-child component to keep code tidy.
Problem is, that i can not access the inner Nuxt page, so any editing will be impossible (I want to achieve some simple inline-editing).
For visualization the editor of webflow may be helpful (Directlink to the video). What i want to achieve is a similar version. I would like to have the page separated from the CMS. The CMS would be the lower bottom-bar and provide stuff like the editor for the inline-editing.
Currently my best solution was to define the editing directly inside the page, which is working, but needs to be stripped out for production and makes a future separation impossible.
Is there any solution for this? Or am I thinking the wrong way?
Can I link both instances with a common vuex-store?
You could created two seperate components, one for editing and one for rendering.
These could utilize components themselves to keep the overhead to a minimun.
You could also use the same component, but lazy load the editor features based on some condition like:
If youre fine with having the Editor only available during development you can create an env variable and check for process.env.NODE_ENV !== 'production'
Another way would be to have some sort of authorization that combined with v-if would show the editor or hide it.
As the title implies, I need solid SEO and thus I need to have all the HTML loaded on my site on initial load. However, because the backend is written in PHP, and because it would be more work to write my Vue components with the server in mind, I don't want to use server-side rendering (SSR).
That leaves me with the option to send HTML over the wire, the "old school" way. What I am thinking of doing is writing each page's HTML like normal, but make one of the root html elements a Vue element in order to "upgrade" it. So the initial load downloads the finalized HTML, with all the data (tables, lists, etc already populated), but then after all the scripts are loaded, javascript can take over to make things easier and give a better UI experience. This poses a few questions, however:
Am I limited to a single component, the root? It'd be nice to still have many sub-components that would each have their own state. Perhaps inline templates can be used somehow?
Vue templates have their own templating system, like the mustache braces for displaying variables {{ myVar }}. Will I not be able to use them? The one way I can think of is to create a Vue template (that can be loaded from an external script) that is identical to the part of the HTML that it "takes over". The downside is that I'd have to maintain that component both in the original HTML and in the vue template.
Are there any good examples of what I'm trying to accomplish here?
Edit: I want to clarify that I'm aware I can put in various components here and there throughout the page. This still poses the question of how to make those components already start out rendered. Better yet would be to turn the whole page into Vue, much like an SPA.
I need solid SEO and thus I need to have all the HTML loaded on my site on initial load.
This is not entirely true. Google (80% of search traffic) easily parses SPAs now, so SSR purely for SEO isn't required anymore.
But to answer your question in general, you should check out Laracast's Vue.js series. They go in-depth on how to use PHP with Vue.js (including templating and variables).
I'd ask what it is you want to achieve with Javascript/Vue.js in your page. If everything is already rendered in PHP, does Vue provide a simple UX enhancement or takes over most of the page's heavy lifting (navigation, etc.)? If you have no reactive data and want Vue to simply be a controller for rendered components, then knock yourself out, although it might be approaching an 'overkill' scenario.
Have you looked into Prerender SPA Plugin ( https://github.com/chrisvfritz/prerender-spa-plugin )?
It is offered in the Vue documentation as a viable alternative to server side rendering ( https://v2.vuejs.org/v2/guide/ssr.html#SSR-vs-Prerendering )
Recently I've developed a multi-page application using Vue, here is how i tried to solve the SEO (Maybe this can help you ):
Htmls of header and footer (and other main common components) are packed to the page.html(eg: home.html, search.html).
Script and style are of header and footer imported in page.js(eg: home.js, search.js).
Add div.seo-zone to page.html's div#app, which includes the main SEO data(using some h1,h2,p,div and so on), and add
.seo-zone {
display: none;
}
in your css.
4. Make sure your app's root component's el is '#app'(each page's main content can be a Vue app).
Develop your app as usual.
After Vue rendered, the div.seo-zone will be replaced with your Vue components (although it can not be seen)
Protractor 1.7.0 has introduced a new feature: a new locator by.deepCss which helps to find elements within a shadow DOM.
Which use cases does it cover? When would you want to reach elements in the shadow DOM?
The reason I ask the question is that I'm missing on the motivational part of the matter - I thought about protractor mainly as a high-level framework that helps to mimic real user interactions. Accessing shadow trees sounds like a very deep down technical thing and why would you want to do it is confusing me.
To answer your question, here's a related question: "what information does shadow dom provide that looking at raw html does not?"
The following snippet creates a shadom dom (view via chrome or firefox):
<input type="date">
If you click on the arrow, a pop up opens with all the dates, and you can select it.
Now imagine you are building a hotel reservation app and you made a custom shadow dom date picker, where it would black out (and not allow user to select) dates when rooms are unavailable.
Looking at the raw html, you see <input type="date">, and the value/dates that a user selected. However, how would you test that the black out UI is working as intended? For that you would need to examine the shadow dom, where the pop up resides.
The reason I ask the question is that I'm missing on the motivational part of the matter - I thought about protractor mainly as a high-level framework that helps to mimic real user interactions. Accessing shadow trees sounds like a very deep down technical thing and why would you want to do it is confusing me.
Doesn't seem so in this website that shows an introduction to shadow DOM. It says that:
Shadow DOM separates content from presentation thereby eliminating naming conflicts and improving code expression.
Shadow DOM mainly helps with separating content to avoid naming conflicts and improving your code expression, making it neater and better (I assume). I am sorry to say that I don't actually use Selenium, so here is a website with plenty more information: http://webcomponents.org/polyfills/shadow-dom/
I hope this helps you!
I have a qml app which is created via two separate ways.
1) via a c++ code during startup
2) via my main.qml as one of the tabs.
Inside the qml app I want to know who is my parent so that I can decide if I should stay on my current page or load some other qml. How to know who is the parent to take such decision?
This question is difficult to answer for a few reasons. Notably, it's not especially clear what you want. The simple answer to your question is that a QML element always has access to it's parent via the exposed parent property that exists on all objects. If your question is more complicated as it appears then you need to rephrase the question to better clarify what you actually want.
I was experimenting with Dojo and Dijit in the past days and I find it quite interesting. I was however trying to find a reference or an API doc that helps me understand all the properties I can assign to widgets and containers.
For example a Tab with a Save Icon will be like this:
<div data-dojo-type="dijit.layout.ContentPane" title="Group Two" data-dojo-props="iconClass: 'dijitEditorIcon dijitEditorIconSave'">
Now, where can I find what to put in the "data-dojo-props" property? Where can I find for example all the list of icons?
My main question would be for example on how to create a vertical menubar, but beyond odd examples scattered here and there, the api reference is not much helpful...
Any help? Am I missing something here?
For this kind of situation, the trick is learning how to convert between the programmatic Javascript style and the declarative HTML style (and sometimes also between the old declarative style, without data).
For the new declarative style, basically the only "real" argument now is data-dojo-props and it consists of an object that will be passed to the widget constructor.
//programatic style
new dijit.myWidget({foo:'a', bar:'b'});
//declarative style
<div data-dojo-type="dijit.myWidget" data-dojo-props="foo:'a', bar:'b'"></div>
You can find what properties an widget accepts by checking the corresponding widget documentation and looking for either declarative or programmatic examples (now that we know how to convert between them). If that is not enough, you can also check the source code - it is usually very well commented and is where api.dojotoolkit.org gets its data from anyway.