Ember.js: Dynamic width based on model attribute value - ember.js

First-time Ember user here. In the app, my model objects are each represented by a rectangular-shaped <div> element. The width of each div is determined by its model's size property. The catch is that the possible values for Model.size are 1-10, not simply pixel values. The div's width is then calculated based on the size. For example, a size of 1 might equal a width of 100px, and a size of 2 would equal 200px, and so on. Thus, these CSS width values need to be calculated and bound to the template. Being new to Ember, I don't yet know where this logic should live. Helper? Controller? Because it's really just presentation logic, it doesn't seem right to have it in the model.
<script type="text/x-handlebars" id="things">
{{#each model}}
<div>
{{description}}
</div>
{{/each}}
</script>
Also, will binding it to the template allow the calculated width to be updated automatically in the template whenever the Model.size value is changed (say, from 1 to 3, thus the div would grow wider)?

While it is a good idea to keep presentation and logic separate, sometimes they need to be mixed. I've certainly had use cases. I used this helper when I had a similar issue. Assuming you had this property in your model:
divWidth: function() {
return this.get('size') * 100;
}.property('size')
You could use this template (which is bound to the property value):
<script type="text/x-handlebars" id="things">
{{#each model}}
<div {{bindStyle width="divWidth" width-unit="px"}}>
{{description}}
</div>
{{/each}}
</script>

I don't think this is the right way to do this, but you should be able to do it this way. You can add a function to your controller (or, I believe your model as well) that listens to the size property for changes, and then calls a jQuery function.
i.e.
changeSize: function() {
return $('#things').css( 'width', this.get('size') * 100);
}.property('size')
Also, you could create a computed property in your model the calculates the size for you:
divSize: function() {
return this.get('size') * 100;
}.property('size')
And you'd reference the divSize in changeSize function, which would be useful if your conversion was more complicated than just multiplying by 100. The helper in the other answer looks useful and more Ember-esque, but here's another way it could be done.

Related

In an Ember Component where should you put reusable code that isn't an action?

I have a standard component defined something like:
export default Ember.Component.extend({
hideIfEmptyChange: function() {
var thingOfInterest = ...;
var otherThingOfInterest = ...;
...
// Perform some logic
...
// Perform some logic using thingOfInterest
// Perform exactly the same logic using otherThingOfInterest
}.observes('hideIfEmpty.#each')
});
I want to move the logic for the last two pieces into their own function to prevent writing out the same code twice just for two different variables.
I could write an action on my component and use this.send('myAction',...) - but would it be best practice to have this as an action if it isn't going to be used (or even usable) from the component's template? If you shouldn't do it this way then how should you?
My other thought was mixin's - but the code here will be completely specific to the component, so again this doesn't feel 100% right.
Edit
The component is used here to observe an array of widgets, which are displayed in a sidebar. To start with the sidebar is hidden away as there are no widgets. When a widget is added the sidebar then slides out using a css3 transition between a bootstrap class I added (col-md-0) and something like col-md-2, at the same time the main column shrinks from something like col-md-10 to col-md-8. Because of the nature of it coming out from zero width the widgets inside squish around during the animation and so need to be hidden during it. So the generic piece of code will be:
function(element, classes) {
var lowWidth = 50;
// Transition looks awful if columns start from small width, so hide inner content until css3 transition complete if starting from low width
if ($(element).width() < lowWidth) {
$('div', element).hide();
$(element).toggleClass(classes);
$(element).on('transitionend webkitTransitionEnd oTransitionEnd MSTransitionEnd', function(e) {
$('div', element).fadeIn(250);
$(this).off(e);
});
}
else {
$(element).toggleClass(classes);
}
}
My component here is in block form and actually has the sidebar within it in the template.
{{#hideable-cols hideIfEmpty=rightSidebarWidgets leftId="det-main" leftMinClass="col-md-8" leftMaxClass="col-md-10" rightId="det-sidebar-right" rightMinClass="col-md-0" rightMaxClass="col-md-2"}}
<div id="det-main" class="col-md-10 resizes">
{{outlet}}
</div>
<div id="det-sidebar-right" class="det-sidebar resizes col-md-0">
{{widget-area widgets=rightSidebarWidgets saveObjectFromWidget="saveObjectFromWidget" removeWidget="removeRightWidget"}}
</div>
{{/hideable-cols}}
The only other way to do what I wanted would have been if I could have set 'inner' components to only be able to react to changes in the array of widgets AFTER the parent block component is happy/done. I've used something similar in knockout js but couldn't see this kind of feature in Ember, so my workaround was to hide the div where the widgets are added, do the transition and show the div again afterward.

Binding to an array or object subscript

I'm wanting to do something that I suspect is quite easy but for some reason can't figure out how to get my head around it:
{{#each item in myArray}}
{{ui-input value=storeMe[#index]}}
{{/each}}
In the above case I'd be iterating through a numeric array of things and I want to store values of a UI component using the same numeric index.
Similarly it would be nice to be able to do the following:
{{#each item in myArrayOfObjects}}
{{ui-input value=storeMe[item.id]}}
{{/each}}
Where the storage device -- storeMe -- is a dictionary whose keys are determined by the id property of each item in array of objects.
In my particular use-case, I am asking the user to input a strategy for measuring body fat. I use a select box for that:
<div class="clearfix downer">
{{x-selectize
options=measurementStrategies
labelField="name"
placeholder="measurement strategy"
valueObject=measurementPoints
}}
</div>
By binding to the "valueObject" above I get back a simple array of measurement points which are relevant for the user chosen strategy (e.g., chest, thigh, lower back, etc.). I then iterate through these measurement points and want to have a value stored for each one:
<div class="downer">
{{#each point in measurementPoints}}
<div class="clearfix">
{{ui-number-input value=model.measurements[point]}}
</div>
{{/each}}
This doesn't work, of course, because apparently I can't bind to an offset property (aka, measurements[point]).
In many cases this type of problem doesn't matter because if I want to manipulate the structure I'm iterating over then the each loop provides the indirection. The problem comes when the storage property is hanging off of a different base than that which you are iterating over. So in my case, if I were actually manipulating point or a property hanging off of point this would be easy because point is an offset of measurementPoints but in my case I'm iterating measurementPoints and saving values to model.measurements.
That’s too much logic for Handlebars. You could create a computed property instead that pairs each item with each value in storeMe, so you can access them as pairs.
You could probably accomplish this with a custom helper, but it seems like a mess to me.
Here’s a rudimentary example, lacking detail on your problem domain:
storeMeItemsByIndex: function() {
var storeMe = this.get('storeMe');
return this.get('myArray').map(function(item, index) {
return storeMe[index];
});
}.property('myArray', 'storeMe'),
storeMeItemsById: function() {
var storeMe = this.get('storeMe');
return this.get('myArray').map(function(item) {
return storeMe[item.id];
});
}
Those would fit your example template code. However, you wouldn’t have access to both the value from storeMe and the item at the same time. If you want that, you could just construct object pairs:
storeMeItemsByIndex: function() {
var storeMe = this.get('storeMe');
return this.get('myArray').map(function(item, index) {
return {item: item, value: storeMe[index]};
});
}.property('myArray', 'storeMe'),
Or something like that.
With your more specific example, you could do something like this:
measurementPointsWithValues: function() {
var measurements = this.get('model.measurements');
return this.get('measurementPoints').map(function(point, index) {
return {point: point, value: measurements.itemAt(index)};
};
}
Then you’d use it in your template like this:
{{#each pointAndValue in measurementPointsWithValues}}
{{! some use of pointAndValue.point, probably}}
{{ui-number-input value=pointAndValue.value}}
{{/each}}
It’s clunky, but it works. I don’t know the details of your object model, but you may benefit from some intermediate objects.

Ember View - Recursive view call throws Stop Script Error

I have to construct a tree structure like the below image.
For this I use a Ember View and recursively call to construct the whole tree like structure based on the supplied model.
My Templates are:
<script type="text/x-handlebars" data-template-name="index">
<div class="zd-fldr fleft" style="width:230px;">
<ul class="fldr-sub">
{{#each item in model}}
{{view App.FoldertreeView model=item contentBinding="item"}}
{{/each}}
</ul>
</div>
</script>
<script type="text/x-handlebars" data-template-name="foldertree">
{{#if item.subfolder }}
<span {{action 'getSubFolder' item}} {{bind-attr class="item.IS_OPENED:fdtree-icon:ftree-icon"}}> </span>
{{else}}
<span class=""> </span>
{{/if}}
<span style="padding-top:20px;" class="fdetail fleft" >{{item.FOLDER_NAME}}</span>
<ul style="margin-top:30px;" {{bind-attr class="item.IS_OPENED:showdiv:hidediv"}}>
{{#each item in item.children}}
{{view "foldertree" model=item contentBinding="item"}}
{{/each}}
</ul>
</script>
JavaScript:
App.IndexRoute = Ember.Route.extend({
model: function() {
var treeArray = [];
for(var i=0; i<4000; i++){
var temp_obj = { 'FETCHED_DATA': false, 'FOLDER_ID': i, 'FOLDER_NAME': 'Folder_'+i, 'IS_OPENED': false, 'opened': true, 'subfolder': true, 'children': [] };
treeArray.push(temp_obj);
}
return treeArray;
}
});
App.FoldertreeView = Ember.View.extend({
tagName: 'li',
templateName: 'foldertree',
classNames: ['treediv', 's-fldr']
});
Initially I load only the first level folders from the server by calling an API.
Then when the open node is clicked, the children array is filled by calling an request to the server.
Now when the model length is greater than 3000 "Stop Script" error is thrown in Firefox browser.
In my tree there is no limit for the number of nodes. How can I solve this problem.
Demo JS Bin (Try it in Firefox)
Ember is a web framework. Given that information, you need to realize that you can't efficiently render 6000 items in a browser without reusing some view elements. Even native applications don't do this: in iOS, for instance, the cells in a TableView are reusable, so a table displaying a collection of 6000 items only has enough cells to cover the height of he view and some scrolling overlap. The view is aware of its scroll location, and renders the 10-20 items that need to be rendered from the collection, and when you scroll down it removes the top element, places an element at the bottom, and renders the next item in the data array. This way, everyone wins. I would suggest you do the same, as JS/HTML just can't handle that many elements efficiently.
I know it's not a fun implementation, but once you come up with a component that does this the first time, you'll be glad you did.
Honorable mentions: https://github.com/emberjs/list-view. You're doing a file tree and not a list, which is more difficult than just a long list, but you may still be able to use it if you change up your UI a little bit. If you have the folder structure navigable with a tree and show files in a list-view, this may mitigate your issue depending on whether the problem is with a number of files or a number of folders.
This is not really an Ember issue but a general javascript issue. When a script is taking to long time to execute this kind of errors message are displayed / fired by the browser and it's different on each browser.
You can read this good blog post about long time runing scripts
If you have browser environment undercontroll (i mean your computer our your companies computers) you can still setup firefox to run longer scripts
However a good practice would be to "split" your script in sub task taking less time to execute.
EDIT
Ass discussed in the comments this is due to the Huge number of view you generate. You can have 6000 models returned from your backend however generating 6000 view at once is heavy.
Here is a proposition on how to handle this : http://jsbin.com/zakisoyesi/6/edit?html,js,output free to you to adapt it to your use case and event to make it transparent to the user by using onScroll or any other event.

Combining view class with layout and {{#each}} multiple times gives incorrect behavior

I'm seeing some very strange behavior in this jsfiddle.
I am building an accordion control (hopefully eventually a good contribution to ember-bootstrap), and so I built a view class that uses layout to wrap the contents of the view:
Bootstrap.Accordion = Ember.View.extend({
tagName: 'div',
classNames: 'accordion',
layout: Ember.Handlebars.compile('{{yield}}')
});
Then I use it like so, with the {{#view}} helper, and include an {{#each}} block which will eventually include other views to set up the inside of the accordion control. And in one case so far, I do this twice in the same template, to display different information in two different accordion controls, sort of like this:
{{#view Bootstrap.Accordion}}
{{#each content}}
<div><strong>Field 1:</strong> {{field1}}</div>
{{/each}}
{{/view}}
{{#view Bootstrap.Accordion}}
{{#each content}}
<div><strong>Field 2:</strong> {{field2}}</div>
{{/each}}
{{/view}}
But, as you can see in the fiddle, this produces a very unexpected result. Basically, the second instance of the view is an exact copy of the first. Even the static content inside the {{#each}} block is not right:
Field 1: Instance 1 Field 1
Field 1: Instance 2 Field 1
Field 1: Instance 1 Field 1
Field 1: Instance 2 Field 1
However, if I put something between the {{#view...}} and {{#each}} helpers, it behaves as expected:
{{#view Bootstrap.Accordion}}
Fourth try...
{{#each content}}
<div><strong>Field 4:</strong> {{field4}}</div>
{{/each}}
{{/view}}
So, it looks like something about the similarity of the content directly within the {{#view}} helper causes the result to be cached by Handlebars...or something. That's just a wild hypothesis. Can anyone see what's going wrong here?
(Note that the Bootstrap library is not included in the fiddle, so it can't be that Bootstrap is goofing something up.)
This looks like a bug.
This github issue was created today, only with the {{#linkTo}} helper.
Looks like this is occurring with all block helpers.

Is it possible to loop over a computed Array in Emberjs?

I'm trying to loop over a computed property array in handlebars. In this example, I can do it for an ordinary array, but not a computed array:
http://jsfiddle.net/gh7Qr/
What should the right syntax be to loop over a computed property in handlebars?
Yes, it is possible. But you forgot to return your computed array and you have to add cacheable() to computed properties, which return an object and not a primitive. Otherwise you'll run into an infinite loop (see discussion https://github.com/emberjs/ember.js/issues/38) Also have a look at Gordon Hempton's excellent blog post about current Ember.js gotchas, among others regarding computed properties. However since commit 626d23f the issue with cacheable has been solved.
A corrected example of your code is here: http://jsfiddle.net/gh7Qr/4/
Handlebars:
<script type="text/x-handlebars" >
{{#each App.games}}
{{this}}
{{/each}}
{{#each App.gamesA}}
{{this}}
{{/each}}
</script>
JavaScript:
App = Ember.Application.create({
games: [1, 2, 3],
gamesA: Em.computed(function() {
return this.get('games').map(function(game) {
return game + 'a';
})
}).property('games').cacheable()
});​
​