We have several forms in our application which have made extensive use of widgets.
Unfortunately, this causes the form to load in a very "jittery" manner. It still loads pretty quickly, but you can perceptively see each widget 'pop' into view one-by-one.
Is this an expected side affect of the widget infrastructure, or is there a technique whereby we can coerce Durandal into constructing the entire view (widgets and all) before attaching, which seems to be how partial views work? (We were able to convert many of these widgets into partial views to mitigate the phenomenon).
How to easily reproduce the behavior
Using the HTML samples, find app/widgets/index.html and make a small modification to create a view which will have lots of widgets:
<div>
<h1>Widgets Sample</h1>
<!-- ko foreach: new Array(100) -->
<div data-bind="expander:{items:$root.projects}">
<h3 data-part="header">Project: <span data-bind="text: name"></span></h3>
</div>
<!-- /ko -->
<button class="btn" data-bind="click: addNewProject">Add</button>
</div>
When refreshing the page, you will see the scrollbar "shrinking down" visibly. I suspect this is because each individual widget is being added to the DOM one at a time, rather than "all at once with the parent view" which is how partial views work.
Note: The affect is fairly subtle with this very simple markup, but the more complicated the UI elements, the more noticeable and jarring the "studdering" becomes (especially when you have non-widget content nested in between various wisgets).
Looks like there's no obviouse answer at the moment, but there's an issue at https://github.com/BlueSpire/Durandal/issues/434 that is cross linked with this questions.
Related
I'm trying to wrap my head around how "inner components" can adjust the content of "outer components". Let's say I have an application template that looks something like this:
<template>
<div class="sidebar">
<div>Some app-wide content</div>
<div>
<!-- I want to put some view-specific content here -->
</div>
</div>
<div class="main-body">
<router-view></router-view>
</div>
</template>
Each subview wants to render different content to the sidebar. Obviously this would be easy if the subview included the sidebar area itself, but let's say it is important to preserve the structure and we don't want to replicate the boilerplate of the sidebar across every view.
Is there any way for a child view to declare "export this extra component for display in another place?" I imagine something like injecting the parent view and calling a method on it, but I can't figure it out from the documentation.
Simple demo:
It's fairly simple, actually. Just import and inject your sidebar or any other viewmodel and call a method or update a property.
https://gist.run/?id=745b6792a07d92cbe7e9937020063260
Solution with Compose:
If you wanted to get more elaborate, you could set a compose view.bind variable to that your sidebar would pull in a different view/viewmodel based on the set value.
https://gist.run/?id=ac765dde74a30e009f4aba0f1acadcc5
Alternate approach:
If you don't want to import, you could also use the eventAggregator to publish an event from the router view and subscribe to listen to that event from your sidebar and act accordingly. This would work well for a large app setting where you didn't want to tie them too closely together but wanted the sidebar to react correctly to unpredictable routing patterns by always responding when triggers were published.
https://gist.run/?id=28447bcb4b0c67cff472aae397fd66c0
#LStarkey's <compose> solution is what I was looking for, but to help others I think it's worth mentioning two other viable solutions that were suggested to me in other forums:
View ports. You can specify multiple named router views in a template and then populate them by passing in a viewPorts object to the router instead of specifying a single moduleId. The best source of documentation is a brief blurb in the "Cheat Sheet" of the Aurelia docs.
Custom elements. It's a little more "inside-out" but you could define most of the outer content as a custom element that has slots for the sidebar and the main body; each child view would define this custom element and pass in the appropriate pieces.
I have a so called chat view that basically consists of a repeat.for that loops over all the messages and renders the message views using <compose>.
The problem is that it becomes quite slow once the message count exceeds 50 and the user navigates between chats (which triggers the repeat.for update, as I replace the dataset in the VM).
I feel like I am doing something wrong in regards of handling a view like this. Can I get some input regarding other alternatives?
I have tried UI virtualization, but unfortunately the current plugin does not offer support for features that I require (variable height items, bottom-up alignment).
I have also done quite a bit of optimizations regarding bindings, most are one-time and updates to the dataset are debounced. But this did not improve things, as the main bottleneck is the initial load (binding the views the first time).
Thanks!
Example of current approach:
<li repeat.for="message of chat.messages">
<compose view-model.bind="getMessageViewFromMessage(message) & oneTime"
model.bind="message & oneTime"
containerless>
</compose>
</li>
I think you need to consider not using <compose> at all for this. Is there a reason you need <compose>? When you think about it, the <compose element has to re-run through the same view instantiation/binding logic Aurelia does for everything else, every time a message is displayed.
I would personally create a HTML partial with some bindable properties and inside of the loop, reference it. So you might have chat-message.html and then display it like this:
<li repeat.for="message of messages">
<chat-message message.bind="message"></chat-message>
</li>
Where possible and in most cases it should be, avoid dynamic composition for potentially large sets of repeated items.
You should check out the aurelia-ui-virtualization library. Once you load it, you can replace repeat.for with virtual-repeat.for in places like this and you'll get a virtualized repeater that will help improve perf with this type of situation.
I just come across a good write up for a new ASP.NET Core feature called Tag helpers.
From there, I understood that one can replace the following code:
#model MyProject.Models.Product
#using (Html.BeginForm())
{
<div>
#Html.LabelFor(m => p.Name, "Name:")
#Html.TextBoxFor(m => p.Name)
</div>
<input type="submit" value="Create" />
}
with:
#model MyProject.Models.Product
#addtaghelper "Microsoft.AspNet.Mvc.TagHelpers"
<form asp-controller="Products" asp-action="Create" method="post">
<div>
<label asp-for="Name">Name:</label>
<input asp-for="Name" />
</div>
<input type="submit" value="Save" />
</form>
There's some new syntax such as asp-controller, asp-for, etc. But what does it do? And what's the advantage of this new approach?
The most important improvement I've seen so far is the control it guarantees over your HTML elements. While convenient, the Html helpers used by MVC create problems when you try to do things they weren't built for.
A simple example can be seen when using the TextBox in MVC5:
#Html.TextBoxFor(m => p.Name)
The resulting HTML markup looks like:
<input class="form-control" id="Name" name="Name" type="text" value="">
Nice and simple. But what if you want to add a placeholder attribute? What if you want to use bootstrap's validation states? What if you have some 3rd party super cool javascript library which needs custom attributes. None of these things were possible in the initial release of MVC5. Though they were eventually added via update in the form of htmlAttributes. Even now adding custom attributes is kludgey at best.
#Html.TextBoxFor(m => p.Name,
new {#class="form-control has-error", placeholder="Enter Name",
superCoolFeature="Do something cool"})
While you could argue this is still less code that straight HTML, it is no longer a significant advantage. Worse, this solution still doesn't cover dashes in attributes which are fairly common. If you need them you are stuck with a workaround such as ActionLink htmlAttributes
I've gone down the route of fixing these deficiencies with custom editors, and tried building my own TextBox controls. It became obvious pretty quickly that replacing the included TextBox templates would require a lot of work. Worse, your templates have to have knowledge of any extensions you are adding to use them.
It seems like the inclusion of Bootstrap and other 3rd party tools into MVC have made it more obvious that the current design has problems with extending HTML which need to be fixed. Hopefully the tag helpers implementation is complete enough that we can avoid them in the future.
Not to mention, your Web Designers will have real HTML tags to edit that they recognize to re-design your pages. Designers shouldn't have to be coders and there's enough for these sharp folks to keep up with, studying the moving targets of HTML5 and CSS3 specs.
A few things come to mind:
As #ChrisWalter points out, these tag helpers give HTML tags an Open/Closed quality. Rather than just letting you write extension methods for common HTML patterns, you can extend an HTML element. This lets you pick-and-mix multiple extensions per component, rather than having to choose between them.
HTML Helpers tend to not work super well for elements that need to have inner HTML provided as an argument. They came up with a clever pattern so you can say:
#using (Html.BeginForm(...)){
{
<input ... />
}
But there's nothing about BeginForm() that would force you to put it in a using statement, and there's nothing to prevent you from using incorrect HTML structure. (<input> technically isn't allowed to be directly inside a <form> tag.)
This gives us a really easy transitional stepping stone into the Web Components world of HTML5. A component that you write today for jQuery or Bootstrap to pick up and enhance may make more sense as an Angular 2 or Polymer component in a few years. Using HTML syntax makes it possible to write your HTML the way you want it to look when it's a web component, and have it automatically translated into the structure it has to take on for now (or for specific browsers, later).
Accepted answer is correct but just a correction.
Html Helpers cover dashes in attributes by use of underscore. for example if you want html like
my-attr=value
then you can use html helpers like
#Html.TextBoxFor(m=>m.id,
new { my_attr = value })
then it will convert accordingly.
I know the original question asks about advantages but for the sake of completeness I have to mention one disadvantage:
With tag-helpers enabled you cannot inject C# code inside tag attributes.
I.e. this code will break:
<!-- this won't work -->
<input class="#GetMyClass()">
<!-- this won't work too -->
<input type="checkbox" #(condition ? "checked" : "") >
To work around this problem you can use custom tag helpers or just disable tag helpers altogether like described in this answer: https://stackoverflow.com/a/65281018/56621
P.S. My humble opinion that can be safely ignored: tag helpers are "magic". And "magic" is always bad in programming. If something looks like an HTML tag, walks like a tag and quacks like a tag - then it should probably be an HTML tag. Without me knowning "oh, it's not *really* a tag".
From building a basic web app from the ground up in .NET 7/Razor pages, I haven't encountered a single instance where a tag helper has an advantage over simply coding the HTML. I don't come from an MVC background so maybe that is where the advantage lies but as seen before...Microsoft has released yet another version of wheel-reinvention that instead of making things easier for some simply adds more confusion to others.
I ran into this issue while building my online design portfolio. It seems complex to me, but I know there is a way to do it, so I am frustrated that I can't find a solution. Please help!
My design calls for the use of media queries to optimize my site for mobile, tablets, and desktops/laptops. The mobile version has a single column of thumbnails. When each thumbnail is clicked, a hidden div is revealed below it via jQuery slideToggle, pushing down the other project thumbnails.
That is how the mobile version works and it works great. The problem is the tablet and dektop/laptop versions. For those versions, I want the the thumbnails to display in a grid pattern. Two side-by-side on tablets and three side-by-side on desktop/laptops with infinite rows for all versions. I can make them display in a grid with HTML, but the problem comes when a thumbnail is clicked and it reveals the div below it via slideToggle. Since I'm using media queries, the order of the HTML is still the same as the mobile version and the hidden divs are directly below each thumbnail in the code. Thus, revealing the hidden div pushes down all the other thumbnails, including the thumbnails in the same row as the thumbnail that is being clicked (if they come after it in the code). The last div in each row does what I want it to; the next row is pushed down when the hidden div is revealed. I want the hidden div to display below the row it is in and push down the thumbnails that are in the rows below.
And obviously I want to stick with media queries to avoid creating separate HTML, if possible.
Repeating HTML for the thumbnails and hidden divs:
<div class="body">
<div class="thumb"></div>
<div class="projectWrapper"></div>
<div class="thumb"></div>
<div class="projectWrapper"></div>
<div class="thumb"></div>
<div class="projectWrapper"></div>
<div class="thumb"></div>
<div class="projectWrapper"></div>
<div class="thumb"></div>
</div>
I created a jsfiddle to demonstrate the problem: http://jsfiddle.net/EuHyc/13/
Please note that the divs are hidden using jQuery. Hiding them with CSS was not allowing my content within the hidden div to display properly when revealed. Also, I had to use display:inline-block because float:left does not force the hidden div to appear below it in the layout.
I hope I adequately explained the problem. Thanks in advance for any help! I sincerely appreciate it!
I've created a RDFa snippet to use on a client's website using the GoodRelations tool. The generated code creates the tags as expected, but there's no text between the divs, for instance:
<div typeof="vcard:Address">
<div property="vcard:locality" content="Yorba Linda"></div>
</div>
I'm assuming that this is OK, and that I am expected to put descriptive text for humans between the 'locality' divs without any adverse effects (in relation to SEO.) Correct?
As William says: In most cases, is is impractical to reuse visible content for publishing meta-data, because they differ in sequence or structure. In that case, it is better to put all meta-data in a single block of <div> elements without visible content. This is called "RDFa in Snippet Style", see
http://www.ebusiness-unibw.org/tools/rdf2rdfa/
Hepp, Martin; García, Roberto; Radinger, Andreas: RDF2RDFa: Turning RDF into Snippets for Copy-and-Paste, Technical Report TR-2009-01, 2009., PDF at http://www.heppnetz.de/files/RDF2RDFa-TR.pdf
Google is consuming such markup, despite a general preference for marking up visible content. Many big shops are using this approach with good results, e.g. http://www.rachaelraystore.com/Product/detail/Rachael-Ray-Stoneware-2-pc-Bubble-Brown-Baker-Set-Eggplant/316398
So if you can integrate the visible content and the RDFa constructs, then use
<div typeof="vcard:Address">
<div property="vcard:locality">Yorba Linda</div>
</div>
If you cannot, then use
<div typeof="vcard:Address">
<div property="vcard:locality" content="Yorba Linda"></div>
</div>
...
<div>
<div>Yorba Linda</div>
</div>
But the divs with invisible content must be close to the visible content and be placed better before than after the visible markup.
From and RDFa point of view, it is fine (I am assuming you are using bracers because you don't know how to escape greater than / less than characters).
The only thing you need to think about is how adding this fragment of HTML to your HTML document, will affect the rendering. Based on the fact that you are using the content attribute, this fragment is destined to remain hidden. So yo should think about this in relation to the CSS architecture. My advice would be to create a specific CSS class that is for annotations.
Having spoken to the author of Good Relations, his advice would be to put this fragment before any other HTML element in the body of your document. Generally, the Rich Snippets team indicate that they ignore hidden RDFa, but it doesn't actually matter and really in the long run it enables the publishing of RDF to anyone (not only Google) who wants to consume it.