Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Ember 1.8 Beta
Search
Martin Muñoz
September 11, 2014
Programming
0
90
Ember 1.8 Beta
Martin Muñoz
September 11, 2014
Tweet
Share
More Decks by Martin Muñoz
See All by Martin Muñoz
Anatomy of HTMLBars Templates
mmun
8
1.3k
Other Decks in Programming
See All in Programming
私の後悔をAWS DMSで解決した話
hiramax
4
210
基礎から学ぶ大画面対応(Learning Large-Screen Support from the Ground Up)
tomoya0x00
0
410
時間軸から考えるTerraformを使う理由と留意点
fufuhu
15
4.6k
Kiroの仕様駆動開発から見えてきたAIコーディングとの正しい付き合い方
clshinji
1
210
go test -json そして testing.T.Attr / Kyoto.go #63
utgwkk
3
280
CJK and Unicode From a PHP Committer
youkidearitai
PRO
0
110
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
unachang113
4
2.7k
アプリの "かわいい" を支えるアニメーションツールRiveについて
uetyo
0
220
意外と簡単!?フロントエンドでパスキー認証を実現する WebAuthn
teamlab
PRO
2
720
もうちょっといいRubyプロファイラを作りたい (2025)
osyoyu
0
400
ProxyによるWindow間RPC機構の構築
syumai
3
1.1k
実用的なGOCACHEPROG実装をするために / golang.tokyo #40
mazrean
1
250
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Speed Design
sergeychernyshev
32
1.1k
KATA
mclloyd
32
14k
A better future with KSS
kneath
239
17k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
111
20k
Why Our Code Smells
bkeepers
PRO
339
57k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
Git: the NoSQL Database
bkeepers
PRO
431
66k
RailsConf 2023
tenderlove
30
1.2k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Become a Pro
speakerdeck
PRO
29
5.5k
Transcript
ember 1.8 beta and metal-views By Martin Muñoz
I work at Crowdmark still @_mmun on twitter :(
warning: the typography of this presentation will aggravate you
what’s new in ember 1.8 beta?
i don’t actually know
we’re still using Ember 1.5 at Crowdmark!
here’s what they tell me…
IE 6 and 7 are deprecated.
[applause]
what does that mean?
we still support them. please report issues.
Deprecate global access to view classes from template {{view App.PostView}}
Deprecate global access to view classes from template {{view App.PostView}}
Deprecate global access to view classes from template {{view "post"}}
Deprecate global access to view classes from template {{view "post"}}
“but I use multiple namespaces :(“ window.Blahg = Em.Namespace.create(); Blahg.PostView
= Em.View.extend(...);
np! {{view "blahg/post"}}
some big performance improvements…
Lots of string operations are now cached: - camelize/dasherize/whateverfy -
a hash lookup to tell if a path is global - a hash lookup to split
backburner’s pushUnique got a lot of love. This has a
big effect on: - Ember Data - rendering big {{each}} blocks
Thanks Stefan!
Hmm.. what else happened…
None
[ the font is called Flesh Wound ]
The metal-views rewrite entirely removes the dependency on the metamorph
package
Consequently, you will no longer see metamorph script tags
[applause]
how is that even possible?
it’s really simple!
we still use script tags!
…but they are immediately removed and replaced with two empty
TextNodes
I’ll talk more about it some day.
Today, I want to talk about bindings.
Today, I want to talk about bindings.
{{comment-list comments=model}} Specifically, how does this work?
obj from to Binding
commentListView from to Binding {{comment-list comments=model}}
commentListView from “comments” Binding {{comment-list comments=model}}
commentListView “_parentView.context.model” “comments” Binding {{comment-list comments=model}}
The job of bindings: • observe both sides of the
binding • if either side changes, schedule an update on the runloop • break ties: down always wins.
{{#each item in items}} {{name-tag name=item.name}} {{/each}} how does binding
to keywords work? how? :(
nameTagView “templateData.keywords.item.name” “name” Binding {{name-tag name=item.name}}
This doesn’t use bindings, but instead uses its own way
to resolve keywords. {{item.name}}
Ok who cares?
Well, I think its cool but…
{{#each item in items}} {{name-tag name=item.name}} {{/each}} what happens when
items changes?
Because of some complications and some others, the entire each
view much be re-rendered. So we can’t do any smart React style diffing or anything at all smarter than “actually rerender everything”.
In order for Ember to get better, we need to
improve how keywords work. It will have far reaching consequences on the composibility of components
Have you ever used _view or _view._parentView?
We can do better!
The solution we’re working on is streams.
[gasps]
It’s not done yet, and I haven’t figured out how
to explain it very well.
{{myvar}} {{#if myvar}} {{myvar}}!! {{/if}} {{x-foo value=myvar}} {{#each item
in items}} {{name-tag name=item.name}} {{item.name}} {{/each}}
{{myvar}} {{#if myvar}} {{myvar}}!! {{/if}} {{x-foo value=myvar}} {{#each item
in items}} {{name-tag name=item.name}} {{item.name}} {{/each}}
(obj2, to) Stream (obj3, to) (obj1, to) source