#emberjs

> <locks> https://github.com/ember-cli/ember-cli/blob/845...

tmp dir got to .gitignore on march

s/git/npm/

that's what robert said

it got fixed in 0.2.1

Jibuti: i dont think that is overkill, if you do it smart. there is a balance between managing a bunch of components, when it might be easier to throw in a few bount attributes/classes instead?

Jibuti -- i think it's a good idea

Grapho SaladFork thanks, so i go for it

If it stops code duplication then it is a plus in my books - for the most part Jibuti

:)

locks: I was answering to <Grapho> are they poorly maintained is that why they are causing cli issues?

oh sorry

Btw, you could also add .idea to the npmignore

5:02 PM <Jibuti> i thinking about to make a component out of each element (if it repeats more then 2 times)

I have plenty of components that I only use in a single place

same

.idea does not cause any issues, but it's present in 64 packages.

ChALkeR: that's on you though

locks: ?

ChALkeR: like, it's not ember-cli's responsibility to ignore .idea

Ok then. Not my problem =).

you should add it to your own npmignore though

I do not use emberjs.

and yeah, less junk in the repos would certainly be great

I just noted that .idea dir is commonly present in ember-*** packages.

I'm pretty sure it's a common pattern in non-ember packages too

that's all I'm saying

And if .npmignore is created by emberjs-cli, then it could be added there by default.

non-ember packages do not usually have a default npmignore =)

like swp files and DS_Store in OS X

+locks are your components in separate folders like form/input, form/select, page/header, table/row, table/cell etc...? there was a discussion on the cli github page about this. has this been implemented yet? (now i use simple prefixes form-select, table-row etc...)

Jibuti -- you can definitely nest components today

on stable

ChALkeR: does that mean that all the garbage goes into the package?

though a hyphen is still required

Morning all - is there a way to add a computed property to a Model which shows the length of an association - only counting the items which have been saved (have ids)? The only way I can think of at the moment is a this.get('myChildren').map(...) mapping for those with ids

aka

component names need to be hyphenated

form/form-input or such

like SaladFork mentioned

locks: Why are .bowerrc and .travis.yml included by default? =)

SaladFork +locks like this: my-table/my-cell or like this: table/my-cell ?

those aren't text editor files

Does anyone know if http://emberjs.com/deprecations/v1.x/#toc_bindi... is related to {{bind-attr}}?

Jibuti -- either will work

Ok.

I don't actually care about .idea =)

I want to see if there are any associated models (that have already been saved) present - is there a more idiomatic way than just mapping the response from this.get('Chidlren')?

SaladFork ok so one hyphen is enough ;)

Frozenfire_ -- bind-attr was the old way of binding to attributes (one of which may be style)

Frozenfire_: if you're bind-attr style yes

Frozenfire_ -- this is related to, but a separate concern than escaping style strings

SaladFork: we only ever bind-attr class so will that count?

Jibuti -- yes, and it must be in the last "segment" of the path (the component name)

SaladFork ok thanks

Frozenfire_ -- Yes, though mind you bind-attr is deprecated

if you just bind-attr class you don't have to worry about escaping

locks: Actually I don't care even about the `tmp` dirs in `emberjs-**` packages.

hey guys, we're hiring a full-time ember.js developer (contract, remote) https://gist.github.com/brian-gates/7dc1d47ff7a...

ChALkeR: yeah, but that was an actual bug

s/emberjs/ember/

like, bowerrc and travis.yml are files generated by CLI

SaladFork: So to remove those deprecations I should switch my {{bind-attr}} to class="{{prop}}"

when you create an application/addon

so they need to be ignored

Ah, ok.

locks: That was just one of junk-related issues that I filed today.

Frozenfire_ -- yes

i.e. https://github.com/petejohanson/angular-hy-res/...

SaladFork: Thank you, the documentation that I linked above doesn't make that very explicit

I have a form and I don’t really want computed properties that rely on one of the bound attributes in there to update until someone saves the form

yeah, mostly no one cares about package hygiene :P

Frozenfire_ -- i'm surprised there's no mention of bind-attr in the deprecation gudie o_O

my understanding is what i probably want is to copy my object and edit that, then merge my changes on the save action

Frozenfire_ -- see: http://emberjs.com/blog/2015/03/27/ember-1-11-0...

is there a tool or design pattern for this, or should i roll it myself?

SeanLazer -- ember-cli-buffered-proxy

SaladFork: perfect, thanks!

ChALkeR: thanks for filing the issue though

thankfully it's already patched

It's sad that noone cares about those 80+ packages =).

Vaporware &trade;

SaladFork: Thank you, sorry got caught up in reading :)

np :)

Hey all - one more question: When a request comes in to my API for a Parent, the API responds { id: ..., info: .. children_ids: [...] }; however, when there are no children, children_ids: is not present. When making a request in the Parent show route to `this.get('children')`, Ember sends out a request to my API's Children index endpoint, but with no 'children_ids' attribute, which would return *all* children - but I have it 400in

right now, because that's a bad request. Is there a way to have ember recognize that that's a request which should never occur unless it includes either the Parent ID or the Children IDs as expecteD?

Actually, it happens on .reload()

hum

locks: btw, https://gist.github.com/ChALkeR/7bd0f45323b9d03...

if the payload returns an empty array for children_ids, that problem should solve

momomomomo:

rather than return no property at all?