I would like to know tools support for dustjs templating for following.
WYSWYG visualisation. Is there a tool using which I can preview the html template while I edit in dustjs template file.
Automatic creation of templates from wireframes. Is there a tool to create .dust files from .html.
Is dust integrated with any CMS tool? like handlebar in Adobe Experience Manager.
If you know of any good tools for dust js please let me know. I would be using sublime / atom/ eclipse IDEs.
To preview a Dust file automatically as you change it, you'll first want to set up automatic Dust compilation. You can do this using the built-in dustc tool, or via a Grunt plugin like grunt-dustjs.
If you're using dustc, you'd do something like this:
dustc --output=lib/compiled.js --watch templates/**/*.dust
Now, any time a .dust file inside your templates directory changes, the templates will be recompiled and placed into lib/compiled.js. You can load this file on your page and render Dust how you normally do.
Then you can use something like BrowserSync to reload your app in different browsers to get a WYSIWYG preview, or wire it up yourself using a Grunt task like grunt-contrib-watch.
Any HTML file is a valid Dust file. The .dust file extension isn't special! You can even pass files ending in .html to the Dust compiler; it doesn't care. So if you create templates from sliced PSDs or other wireframe tools, they can be compiled as Dust templates. All you have to do is add the appropriate variables.
There are no WYSIWYG editors available that integrate with Dust (but Stack Overflow is not the place to obtain tool recommendations anyways).
Related
Is there a way to mass convert existing Vue.js templates (single file components) into Pug (Jade)?
Something similar to the erb2slim gem for rails.
I find Pug much more legible and its impractical to rewrite an existing open source project.
Many thanks.
There are a few Jade converters like Html2Jade as you're just converting the html. It even appears to keep vue directives including shorthand :bind and #on.
The downside is that it's a manual converter so you will have to paste in each component separately.
In an Angular style app, I would expect the typescript files to be bundled together and basically all loaded at start up of the app. In an MVC type app (a view per page, not a SPA), I would expect to only load typescript for that page. I don't want to load typescript that is not relevant for that page.
I split my typescript into separate files (basically one class per file). I then set up import/export clauses in the files to reference the classes. I think this approach will work better when I go to use external libraries (jquery, etc). If I use namespace, later on when I go to use third party libraries I don't think it will work.
However, that means I need to look at some sort of loader. If I have lots of little typescript files I don't necessarily know when all files have loaded before attempting to use them, which is the sort of thing that requirejs looks after. I haven't used web pack but I think it does the same sort of thing?
But that would mean I would need a requirejs config for each MVC page which doesn't seem to be very efficient. What approach should I be taking to load all the typescript files I require for the specific MVC page, bearing in mind I could end up with dozens of MVC pages?
There is now (2021) a partial solution to this question. I'm not sure it is "efficient" but it does load multiple Typescript files on different MVC pages.
If you alter your typescript config to output ES6 modules, tsc will create one JS file fore each TS file, each in an ES6 module. If you then use a module script tag, the browser will import the files as needed
<script src="scripts/modules/start.js" type="module"></script>
<!-- and/or -->
<script type="module">
import { loadStats } from 'pages/homepage.js'
<!-- note that this is JavaScript -->
loadStats();
<script>
This does require users to be using a modern browser: https://caniuse.com/es6-module
This is not a panacea - there are lots of gottchas and work arounds, one big one being that import statements must be in JavaScript Module style, not TS style
import { loadStats } from 'pages/homepage' // <-- Will not work at runtime
import { loadStats } from 'pages/homepage.js' // <-- Use this style. Note the JS extension
as tsc does not correctly convert import statements. This should point at the TS file (as the created JS files will have the same relative path), Visual Studio appears to be able to cope for the purposes of intellisence and compiling.
We managed to get npm to work for typings, but struggled for other packages. We have, though, been able to retro-fit typescript into an older MVC app this way (we wanted/needed type checking for API calls).
I have a large rails application that I am wanting to split out into smaller applications. The one piece of this application that will be universal to all smaller applications is the mast and footer. I would like to extract the html, javascript and css for the mast and footer into it's own package that each app can load and render.
The main issue I'm running into is that the apps will likely not all be written in rails. Some will be rails, some will be expressjs, some written in Go, and some may end up being written in other languages, so my solution needs to be language agnostic.
My thought is that I can extract the html, css and javascript into it's own git repo, use mustache templates for the html, and then use grunt or a similar build tool to build a gem, a package.json structure and a golang module. Possibly each in it's own git submodule.
I'm curious if there is a more standardized way of doing this. Or if anyone knows of a simpler way of achieving this goal.
Sounds like the technology in common is HTML/JS/CSS.
Wouldn't it be better to export the mast and footer as a self contained JS library, or more precisely, as widgets?
So whatever the application server tech stack would be, you could always generate the HTML in the form of:
<script src="your_widgets.js"></script>
<script>new Footer.render('id_of_dom_element_to_render_to');</script>
By doing so, whether you want the widget library to load the template or you want to embed the template into the widget library or whether you want to simply just construct it using HTMLFragment will not be limited by the server tech choice.
I'm taking a look at Hogan.js by Twitter.
http://twitter.github.com/hogan.js/
They talk about being able to precompile templates via the server which I understand can be a perf gain.
Currently every time I render the template I perform the following after an AJAX hit to the server to get data:
var template = Hogan.compile($('#seasonsTmpl').html());
$('#main').html(template.render(data));
Given the following template:
<script type="text/html" id="seasonsTmpl">
<ul>
{{#season}}
<li>{{.}}</li>
{{/season}}
</ul>
</script>
What can I do to "precompile" server side using an ASP.MVC backend? Is this not possible as it seems to be centered around using Node.js?
You have the right idea to optimize your templates. There are two options, and the choice probably depends on whether you want to render your templates client-side or server-side.
If you want to render them client-side, you can do a true precompile using Hogan.js. Yes, this does not run on .NET, but I think you've misunderstood when precompilation is possible. Rather than expecting it to happen on each web request, or page load, you can compile your templates up-front as part of your build process. You will need to install node and npm to set this up, but you only need to run this locally on your own machine, or a build box if you use one. Whenever you update your templates, you would run Hogan again to update the output file. The compiled output will be a JavaScript file full of functions that are optimized for later use. These functions include your template strings, along with the logic to render the data a la Mustache. You can then include the output file just like any other JavaScript include, or include it with the other sources for minification if you do that.
The second option is to render the templates server-side. This is different than precompilation, the server will compile and render the templates again for each web request. Step away from Hogan.js and look at a .NET alternative such as Nustache. The great thing about Mustache is it has a spec and has been ported to several server-side languages.
There's a fundamental difference in these options in terms of where the rendering happens. You might even want to leverage both approaches in certain scenarios, say if you want to render the initial page load server-side using Nustache, but have dynamic elements that must be rendered in the browser using templates precompiled through Hogan.
More info:
Nustache on Github
I hope you find this helpful!
I have js lint installed in Vs 2010 as a extension through the extension manager.
It finds lots of errors but they are all from external plugins or from the jquery library. I am not going to go and fix stuff in an external plugin or jquery file. So how can I get it to not check these files?
I am also wondering how can I get it to ignore checking href links. I am using asp.net mvc so my links are like this
reg
So it can't find this path as it is the path to the controller action method not a file. So how can I get it to not look at these?
Thanks
You can exclude files (external plugins, jquery, etc.) from the JSLint validation process.
From here.
For the href issue, if you don't have any JS in your views, you could exclude those as well using the method above.