+ All Categories
Home > Technology > What we've learnt from Ember.js - The family talk april 2015

What we've learnt from Ember.js - The family talk april 2015

Date post: 18-Jul-2015
Category:
Upload: wisembly
View: 57 times
Download: 0 times
Share this document with a friend
37
What we've learn from Ember.js after 2 months developing our new product MVP Presentation The Family - 9 avril 2015
Transcript

What we've learn from Ember.js after 2 months developing our

new product MVP

Presentation The Family - 9 avril 2015

About us

Guillaume Potier

Co founder & CTO @guillaumepotier

Nicolas Chenet

Javascript developer @nicolaschenet

About us

http://wisembly.com

About us

http://getsolid.io

About us

4,9 yrs old

38 employees

10 tech + product

About us

BackboneJS

BackboneLayoutmanager

BackboneRelational

Custom

Mocha

Expect

Phantomjs

Gulp

Bash

Symfony2 - MySQL - Redis - RabbitMQ

Welcome to the javascript Jungle!

Welcome to the javascript Jungle!

Welcome to the javascript Jungle!

About us

BackboneJS

BackboneLayoutmanager

BackboneRelational

Custom

Mocha

Expect

Phantomjs

Gulp

Bash

EmberJS

Ember-CLI

Ember Data

Phantomjs

Symfony2 - MySQL - Redis - RabbitMQ

Ce qu’on a choisi

Because it’s a matter of choice

Ce qu’on a choisi

13

Ember JS

Ember CLI

• The command line interface for ambitious web applications.

Ember Data

• A data persistence library for Ember.js

Because it’s a matter of choice

Ember JS ?

En bref…

Ember JS ?

15

Framework pour Single Page Applications

Model / View / Controller

• Model: Classe avec propriétés et comportements (data)

• View: Interactions avec le DOM / Templates …

• Controller: Présentation des datas / Actions …

Rôle important des routes

• Responsable du fetch des datas

• Nesting

• Application state

En bref…

Ember JS + Ember CLI

Pourquoi on aime ?

Ember JS Pourquoi on aime ?

17

TOMSTER !

Ember JS + Ember CLI Pourquoi on aime ?

18

Data Binding et Computed Properties / Observers

• L’interface reflète en permanence la data

• Pas besoin d’écrire des listeners pour mettre à jour les

templates => gain de temps / moins de boilerplate

• Computed properties => des propriétés “fonctions”

• Observers => Réaliser des traitements dès qu’une propriété est

mise à jour

Ember JS + Ember CLI Pourquoi on aime ?

19

Backburner, formerly “The Run Loop”

• Not really a loop

• Tout les traitements sont organisés dans des files spécialisées

• Ex: on s’assure que toutes les opérations de sync soient

terminées avant de rendre les views

sync actionsrouter

transitionsrender

after

renderdestroy

Ember JS + Ember CLI Pourquoi on aime ?

20

Les components

• Approche DRY et “organique” de l’interface

• Les éléments d’interface sont responsables d’eux-même et sont

capables d’interagir avec l’extérieur

• Simple à mettre en place

Les actions, mieux que ng-click

• Equivalent de ng-click mais pas que

• Traitement “smart” des actions grâce au bubbling

Ember JS + Ember CLI Pourquoi on aime ?

21

Ember Inspector, plugin Chrome incontournable

• Arbre des vues et templates

• Arbre des routes

• Représentation des datas, model par model

• Liste des Promises

• Performances de rendu

• Les modules chargés

• …

Ember JS + Ember CLI Pourquoi on aime ?

22

Convention over Configuration

• Une architecture d’application structurée

• Des comportements “automagiques”, qui sauvent du temps et

pas mal de boilerplate

• => Fast developer onboarding

• => A mesure que l’app grossit en taille et complexité, code

toujours clair, identique

Ember JS

Un hamster, c’est parfois difficile à apprivoiser

Ember JS

24

La fameuse Learning Curve

• Où je range mon code ? Je fais un MIXIN ou un SERVICE ?

• Il s’est passé quoi là ?

• La bipolarité du dévelopeur débutant avec Ember

The “Ember way” to do things

• Parfois on peut se sentir “enfermé”

• Les overrides ne sont pas forcément toujours évidents

I18n ?

• Pas de support natif

• Les plugins existants ne correspondaient pas à notre méthode

• Création d’un plugin => ember-gettext

Un hamster, c’est parfois difficile à apprivoiser

Ember CLI

En bref …

Ember CLI

26

Interface en ligne de commande pour les applications Ember JS

Inspiré par Ember App Kit

Structure de projet

Assets pipeline + Server

Gestion des environnements (PROD / DEV / TEST)

Rajoute de la convention dans la convention \o/

Et plein d’autres trucs…

En bref…

Ember CLI

Pourquoi on aime ?

Ember CLI

28

The future is now

• Transpiler ES6: imports / exports sans passer par requireJS

Générateurs et blueprints

• “yeoman-like”: générer des routes / controllers / … en ligne de

commande

• basés sur des blueprints personnalisables: s’adapte à vos

besoins

• Up de productivité et de qualité du code

Server + Live reload

Des tests facilités

• Built in QUnit, Ember Testing, Ember QUnit

Pourquoi on aime ?

Ember Data

En bref…

Ember Data En bref…

30

Models

• Représentation des datas sous forme d’“entités”

• Relations

Adapters

• Abstraction des méthodes de fetch, de sauvegarde

des models

• 1 adapter global ou 1 adapter par model

• RESTAdapter / LSAdapter / FIXTUREAdapter / …

Store

• Gère le cycle de vie des models

• Communique avec les adapters à travers une API

unifiée

• Automatic caching

Ember Data

Pourquoi on aime ?

Ember Data Pourquoi on aime ?

32

Adapters => Quick prototyping

• Models pour lesquels l’API existe / est prête => RESTAdapter

• Model sans API existante => FIXTUREAdapter

• Quand l’API est prête, il “suffit” de changer l’adapter, et voilà

Abstraction des calls à l’API

• Ex: pour fetch 1 meeting => this.store.find(‘meeting’, 123) (peu

importe l’adapter)

• Les URLs sont buildées par Ember Data

• Force la rigueur

Records flags

• record.isDirty => des changements pas synchro

• record.isNew, record.isSaving, etc…

Ember Data

Les trucs moins cool

Ember Data Les trucs moins cool

34

Très très “opinionated”

• Et en plus pas du tout permissif “out of the box” => certains ont

encore mal au crâne

• Difficile à domestiquer avec une API pas forcément en phase

avec son interprétation de la JSON API

Certaines parties des adapters et du store ont du être

réécrites

Essentiellement fait pour la synchro des datas

• Je fais comment si j’ai pas que du GET / POST / PUT / DELETE

sur un model, mais que j’ai besoin de faire une “action” =>

augmente le store ;)

Pour finir

Parce qu’il faut bien une fin

Pour finir

36

Alors heureux ?

• Venant d’un univers Backbone, OUI !

• Moins de Boilerplate

• Code plus concis

• Meilleure qualité

• Tests plus faciles / rapides à écrire

Ce qui a été le plus douloureux ?

• Essentiellement la couche data et comprendre la bête “de

l’intérieur” pour expliquer la magie

Si c’était à refaire, toujours Ember ? Angular ?

• EMBER !

• Cadre / Réel framework qui apportent des fondations robustes

à une app

Parce qu’il faut bien une fin

Nicolas Chenet

[email protected]

@nicolaschenet

wisembly.com

merci, à bientôt !Guillaume Potier

[email protected]

@guillaumepotier


Recommended