We're starting to use Handlebars for the view layer in some of our projects. We are starting to hit a crossroads between two ways of doing some templating. I've been using partials to handle the templating & having small HTML templates like:
<p id="{{name}}">
<label for="{{name}}Input">{{text}}</label>
{{#if info}}
<small>{{info}}</small>
{{/if}}
<textarea name="{{name}}" id="{{name}}Input"></textarea>
</p>
Another developer feels that we shouldn't be using partials for this & instead we should be creating helpers for this.
I can see helpers being easier to handle input parameters (as I'm currently using some form of "include" helper to include these partials with some extra variables). But it doesn't sit right with me that you are writing HTML into strings in code - I don't think you're separating your concerns properly there. We are also using Handlebars in Java (via [Handlebars.Java][2]), so again your HTML is very much in compiled code - not in simple to edit view files.
Is there a generally accepted way to handle templating in Handlebars? Partials or Helpers or is there something else I don't know about?
Well, first you need to understand that partials are very different in handlebars.js opposed to handlebars.java
In handlebars.js, you declare your own partials and call/name them whatever you want in your controller (usually) and then call them within your view. In handlebars.java a partial is defined in your view and is essentially just an include taking a path attribute. Includes are generally integral to most projects and I don't think there's any benefit to dropping such an important piece of functionality.
Also, I've seen the mentality of "use helpers for everything" in many handlebars.js apps and it is becomes difficult to maintain very quickly. Helpers are a great feature but they should be used sparingly. Whenever possible, use the built in helpers and try structuring your data in a way that you doesn't require additional abstracted logic.
Looking at your example, i think thats exactly the correct useage of partial.
Related
I consider using the BEM naming convention in my next project but I'm kind of worried about performances because of the long class names.
Take for example (source is here):
<figure class="photo">
<img class="photo__img photo__img--framed" src="me.jpg">
<figcaption class="photo__caption photo__caption--large">Look at me!</figcaption>
</figure>
In a complex project with dozens of sass files the difference can become non-negligible.
I'm working with Symfony 4 and I wonder if there is an elegant way to replace all css classes in both the css output AND twig templates with lightweight names like a, b, c, ..., aa, ab, etc.
The JavaScript output may also be a consideration because it may add css classes dynamically to certain elements.
For the css part, I think that a Webpack plugin doing global replacements on the final output could be enough.
For the JavaScript, I think it's almost impossible to get it right because the classes names could be generated dynamically (var className = "--is-" + this.state;), or even worse, be returned from the server or any other fancy way you can imagine.
So I thought about adding a prefix to classes that should not be replaced. Like starting them with _.
But the html part (or should I say the twig part) is harder to solve because it can't be ignored like the Javascript part and there is no transformation between the code written in development and the code used in production.
I guess that twig compiles everything into php when the cache is built, so maybe there is something to do using compilation hooks or something is that area.
Do you know any tools that does this kind of thing?
How the big sites deal with this?
For example, if I open the inspector in a Google service I see things like this:
<button class="GBTG6V-f-a GBTG6V-f-l GBTG6V-f-p GBTG6V-f-g" [...]>
Doesn't look very human friendly to me.
Thanks for your insights.
Is it better to use html template (and then html import) to create web components or to use template string? What are pros and cons of these methods?
Using html template files is better for reuse: the same file can be used in different web components. Also they are better displayed in most IDEs as they are recognized as full HTML code.
Using template strings is faster (inline). They don't rely on HTML Imports which is not adopted by every browser vendors. Also you can use template literals to insert directly value of JavaScript variables in the DOM.
Actually there's no much diffrences because there's a workaround for every differences list above (i.e. you can reuse template strings if you save them as text file, or you can load html templates withour HTML imports).
Regarding ASP.NET 4.5's new System.Web.Optimization / Microsoft.AspNet.Web.Optimization:
Can anyone explain the difference in the use of bundling resources using the BundleConfig.cs class file as opposed to the bundle.config xml file?
I've seen some articles showing bundling both js and css in BundleConfig.cs, while others showing bundling js in BundleConfig.cs and css in bundle.config.
I guess I don't understand #1) why you wouldn't just do them both one particular way for simplicity - and #2) why anyone would prefer to hard-code resources like that in a class file? It seems like a much more dynamic approach to just put them in an xml file that can be changed on-the-fly if necessary.
It seems like more articles actually lean toward using BundleConfig.cs than anything else. Is there some particular pro or con that encourages this?
Also, if there is any real documentation on System.Web.Optimization, I would love to know the location (because I sure can't find it).
Thanks-
As far as I can tell, the accepted answer doesn't actually answer the question at all. It discusses the benefits of the bundling framework, but not how using the BundleConfig.cs is different than using the bundle.config file.
A lot of it comes down to whether you prefer working in code or in markup, but each does have some pros that are specific to that method.
For the bundle.config, there's really only a single benefit, but it is a big one. By using it, you can manage bundles without having to touch code at all. This means that you can make changes without recompiling, making quick deployments easier. Also, it means that your front-end developer, who is going to be most familiar with the files that should be bundled, can define the bundles without having to work with any back-end code.
However, there are quite a few limitations on what you can specify in the Bundle.config. For instance, you can't specify any custom transformations to be applied to individual items or bundles. The only bundle properties that you're able to set are the Path, CdnPath, and CdnFallbackExpression. You can't set the Orderer or EnableFileExtensionReplacements properties. You don't have a way to include a directory including all subdirectories (like you can with the IncludeDirectory method). Basically, there's a LOT of functionality that is only available through the back-end code. Granted, a lot of this you could set by using back-end code to retrieve a bundle that was defined in the bundle.config, and then manipulating. But if you're going to do that, you might as well create the bundle in the back-end, also.
My personal philosophy is to use bundle.config unless I need to do something with the bundle that's not possible that way. However, I do agree that having them all in one place is ideal. If I decide I need to use the class, then I'll use that for all of my bundles of that type (I do sometimes put my JS bundles in the class and my CSS bundles in the .config file, though). I'm sure some completely reasonable people would disagree with that process, though.
this documentation explains it all better than I ever could
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
One of the nicest things is this:
The bundling framework follows several common conventions such as:
Selecting “.min” file for release when “FileX.min.js” and “FileX.js”
exist.
Selecting the non “.min” version for debug. Ignoring “-vsdoc”
files (such as jquery-1.7.1-vsdoc.js), which are used only by
IntelliSense.
Can anyone explain the difference in the use of bundling resources
using the BundleConfig.cs class file as opposed to the bundle.config
xml file?
The difference is that you would have to read, parse and load the content of the bundle.config at runtime. Hence, using BundleConfig.cs class file could be simpler.
1) why you wouldn't just do them both one particular way for simplicity
Totally agree.
2) why anyone would prefer to hard-code resources like that in a class file?
Simply put: easy to understand.
It seems like a much more dynamic approach to just put them in an xml
file that can be changed on-the-fly if necessary.
Yes, but you have to write more code to detect when changes happen and then add/remove/replace existing setup. If done poorly, it could lead to UI issues at runtime.
Also, if there is any real documentation on System.Web.Optimization, I
would love to know the location (because I sure can't find it).
Already answered above, but I would repeat: http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
I'm using jQuery plugins in an ASP.Net MVC site.
I've often to include CSS and JS files as required by the plugins I use in every page. So I want to centralize all those dependencies in a single place in my app. thus if a dependency for a given plug-in is changed or updated, I'll only have to modify a single place in my app.
I've thought in two possible solutions:
Extend the HTMLHelper with a partial method
like GetPlugin("jqgrid"); that
will print out all the script and
style tags needed.
Create a partial view for each
pluginlike jqGridDependencies.ascx
that will contain the script and
style tags needed.
Do you have any other idea? what do you think of both proposals?
Could http://combres.codeplex.com/ provide you with a framework for this.
My only personal objection to this method is that each individual pages will have a unique JavaScript/CSS file where as if you combined and compressed everything into one and simply used classes and events to trigger the JavaScript enhancements as and when needed your site would run a lot faster.
I prefer the use of external css and javascript files. There are however many cases where the content of a javascript or css file needs to be dynamic. I'll usually just transfer the javascript or css to inline or inpage code in my aspx page and handle the dynamic stuff there.
Does anyone have a better approach? Would there be a way to generate entire js or css files using asp.net's regular templating language?
I'm currently using webforms but I'd be interested in solving this issue in MVC as well.
Thanks
I've used a HTTPHandler to send back dynamic javascript before. But not something that inherits from System.Web.UI.Page.
Using a HTTPHandler and an ASHX or AXD is the "ASP.Net" way to send back resources dynamically.
I have used handlers for dynamic css. Depending on what you need, you can do the same for js files.
I had a css file with placeholders for the pieces that needed to be dynamic like ##bacgroundcolor##, and the handler just replaced as appropriate.
I have also used an approach where I use css classes to mark html elements that need special behaviors. Then the static js, looks for this elements and hook the appropriate handlers. This is something that certainly would be even easier with jquery (I did it with regular js back then :().
I've done this in an aspx page before, but in my opinion the WebForm style doesn't suit itself well to rendering strictly javascript or CSS. Every time I've done it, the page has ended up looking quite a bit like classic ASP.
hopefully the actual JavaScript you are using would stay static and you would just pass parameters to the JavaScript methods.
I have taken JavaScript code that had been in the markup of a page and containing things like <%= control.ClientID %> and replaced it with static JavaScript. I refactored the code into a class, I then refactored these variable parts into class members. The page creates an instance of the class, with things like ClientID set. The functions can then be static.