productivity
flows & screens
- screen name at top
- transitions below the title
- branching and transitions
"ambitious apps" - applications that have many screens / flows
mapping out an app by screens and flows "flows aren't screen to screen" "nested flows on the screens" github has a hierarchy of flows on a few screens "people end up building a lot of context / nesting in their apps" ^ this is the productivity sinkhole
complexity grows exponentially it's easy at first no matter the tool
flow spaghetti - each flow adds complexity
"every change in flow updates the url" "you as a developer and users expect that any page can go to any other page (through links)"
"small number of screens with lightweight links causes the flow to grow exponentially"
"you want a tool to create new flows productively"
"ember makes you a badass web developer because it makes it easy to add new screens and flows"
vine - the app looks simple but has a lot of flows / screens people don't think about the transition between flows
skylight - ember relieves a lot of the screens / flows
bustle - a content app with ember
travis - deeply nested screens, you can move through them with ease. tabs / builds / screens - easy transitions
diverse applications - all deal with flows dealing with the ember router
even a simple web application has a lot of screens
"no matter how your application ends up working, you can think about the flow between your screens"
"we don't need / want the flexibility we think we need" - DHH
"let's get rid of the productivity sink holes that everyone deals with that are the same - focus on your app"
good defaults keep you on the right path even when it is difficult
"people do the default behavior"
- productivity
- consistently more effective
- especially dealing with flows complex apps
Gains in productivity because of Ember
Rails 2 / jQuery code -> build a new front-end to ember.js ActiveModel serializer / Ember Data to map migration Ember Data provided a natural migration your data can be abstracted
D3 + Ember for visualization packaged as a component d3/ember component - emberjs.jsbin.com/ember-conf-d3/1/edit "frameworks are designed to nudge you in the right direction" "d3 is a library not a framework, we use ember to nudge d3 in the right direction"
The most complicated part is a infinitely scrolling list of video elements Only render one video "How does Vine play videos?"
- post views -> vine controller -> video reference
- switch post view for vine view to play video Swap out dom from lightweight to heavyweight elements remove from the dom when you need to for a better experience
public / private apps instead of two apps, use two routers, a new view, and a couple new controllers send different roles different ember apps leave out parts that you don't need and send them the app
- Collection of Concepts/Ideas
- possibly only JS Framework
- Community
- Fix / Cleanup documentation
- Report and/or fix bugs you find
- submit new features
- File issues / PRs
- Prefix commit (website, guides, main repo)
- [DOC] - master / canary
- [DOC beta]
- [DOC release]
-
test showing regression (if you can)
- jsbin example
-
fix issue
-
prefix commit [FEATURE name-of-feature] [BUGFIX beta] [BUGFIX release] not likely to be done unless it is a big breaking change
-
Security Issues Email security@emberjs.com Work with core team on a fix emberjs.com/security subscribe to the security mailing list
- new api
- backwards compatible but changes the api
- hidden behind feature flags
-
feature flags just an
ifblock that enables features when true -
feature flags allow features to be tested without committing to server helps get the api right
-
features.json show what is enabled
- true: enabled & remove flags
- false: disabled & remove
- null: disabled & left in (can be enabled at runtime)
-
canary features enabled but values are null
-
beta features are disabled
-
release features are disabled
Yes, but it's not a great idea
Yes
EmberENV = { FEATURES: { 'query-params-new': true } };
add to features.json add to features.md
You can't nest feature flags
security audit -> reviewed by core team -> go/no-go decision
3 channels 6 week release cycle
New Features Bugfixes
Branched from canary Bug fixes Doc updates weekly releases
Branched form Beta doc updates security fixes
[DOC] [BUGFIX] [FEATURE] [SECURITY CVE-000-0000]
- Code / data organization in the front-end
- data transformation - easy (tractable)
- easy/unique
- async - medium
- hard/common
- caching - medium
- hard/common
- locality - hard
- hard/unique
- relationships
- "Changes to the api should not impact app code"
- Standardized data retrieval
- single source of truth
packages:Bower build tool: ????
grunt watch
- .coffee
- concat
- sass
- minify
grunt slows down (10s)
var lib = 'lib'
module.exports = libvar lib = 'lib'
var appJs = concat(lib, {
input files: ['**/*.js'],
outputFile: '/assets/app.js'
})
module.exports = appJsvar lib = 'lib'
var libCompiled = filterCoffeeScript(lib)
var appJs = concat(libCompiled, {
input files: ['**/*.js'],
outputFile: '/assets/app.js'
})
module.exports = appJsvar lib = 'lib'
var libCompiled = filterCoffeeScript(lib)
var appJs = concat(libCompiled, {
input files: ['**/*.js'],
outputFile: '/assets/app.js'
})
if (process.env.BROCCOLI_ENV === 'production')
appJs = uglifyJavaScript(appJs)
module.exports = appJsvar lib = 'lib'
var libCompiled = filterCoffeeScript(lib)
var appJs = concat(libCompiled, {
input files: ['**/*.js'],
outputFile: '/assets/app.js'
})
if (process.env.BROCCOLI_ENV === 'production')
appJs = uglifyJavaScript(appJs)
var styles = 'styles'
var appCsss = compile([styles], 'app.css', '/assets/stylesheets/application.css')
module.exports = mergeTrees([appJs, appCss])var lib = 'lib'
var libCompiled = filterCoffeeScript(lib)
var appJs = concat(libCompiled, {
input files: ['**/*.js'],
outputFile: '/assets/app.js'
})
if (process.env.BROCCOLI_ENV === 'production')
appJs = uglifyJavaScript(appJs)
var styles = 'styles'
var appCsss = compile([styles], 'app.css', '/assets/stylesheets/application.css')
module.exports = mergeTrees([appJs, appCss, 'public'])Broccoli only knows trees (a string pointing to a dir, or an object)
tree.read() -> must return a file
tiny API -> big helper packages broccoli-transform
for 1 input tree
transform = function(srcDir, destDir)
broccoli-filter:
for 1:1 file relationships (broccoli coffee is an example)
processString = function(string) { return newString }
broccoli-filter has a cache
doesn't work for sass
Broccoli is a small library
grunt-brocolli
"grunt is a good task runner"
Integrate with backends
broccoli design blog post: bit.ly/broccoli-announcements
follow along: http://ef4.github.io/ember-animation-demo
^ slides are an ember app
"another way to put physical metaphors into computing"
two categories of animations
simple case: animating something within a given route
more complex: animating between routes
willTransition - a hook that will wait for the animation to finish before dismissing
remove irrelevant event handlers to improve performance on mobile
slides: http://t.co/adXx454HmX
- Make a DSL in your HTML
- class/element/attribute
"The inclusion of one thing in something else"
Ember transcludes with "yield" in handlebars
Build Web components as Ember components now
Tapas with Ember
"Ember is awesome at urls"
Adapters: let you talk to the endpoint(s)
Serializers: turn that stuff into what ember is expecting
- HTMLBars is smart about markup
- HTMLBars means no more script tags
- performance of large lists
- HTMLbars can build an element once and cache the fragment
- hydrate / fill in the dynamic parts after
- is actually a rewriting of the ember view layer
- removes recursion for view rendering
- rerendering anti-pattern - everything is bound through the context and bindings will stay in place and won't tear everything down
- bindings keep context and update everything
- "it's just DOM"
- willInsertElement - you'll have the element
- animations
- secure by default
- xss
- server-side rendering
- optional jquery