30
3...4...5...6...

From 3 to 4 to 5

Embed Size (px)

Citation preview

Page 1: From 3 to 4 to 5

3...4...5...6...

Page 2: From 3 to 4 to 5

ExtJS at XeroIt started with a grid.

ExtJS used in Xero and Xero Personal.

Page 3: From 3 to 4 to 5

2012 - 2014• increase in products (via acquisitions)

• increase in developers

• increase in distribution of those developers

• increase in problems we need to solve

• increase in designers

Page 4: From 3 to 4 to 5

FYI: Xero Products• Xero

• MyXero

• SubXero

• Payroll

• Xero Practice Manager / WorkflowMax

• Workpapers

• Banking

Page 5: From 3 to 4 to 5

Xero ContentEnvisioned as a shared library of components based on Ext 4.

2012 - 2014.Deprecated at the end of 2014.

Page 6: From 3 to 4 to 5

We Made Mistakes

Page 7: From 3 to 4 to 5

BIGGEST MISTAKE:Not Understanding What Changed

Page 8: From 3 to 4 to 5

Not relying on Ext for Layout

We just updated an Ext 3 stylesheet until it seemed like "it worked".

Inadvertently this meant we broke Ext layout styles without realising it (till much later).

To deal with this problem applications applied local CSS overrides. Vicious circle.

(c.f. AUI)

Page 9: From 3 to 4 to 5
Page 10: From 3 to 4 to 5

Big Mistake:Not Providing the Right Extension Points

Page 11: From 3 to 4 to 5

e.g. Stores

Thinking in terms of implementations and not "interfaces".

Not thinkng about Stores having a Proxy which has a Reader and a Writer.

Thinking about Stores as just "a thing that does AJAX".

Page 12: From 3 to 4 to 5

Widgets vs. Components vs. Applications

Using components as widgets a la jQuery.

• Trying to render things server-side.

• Not thinking about Front-End as software engineering.

• Thinking about resources on hand rather than the problem at hand:We want to build sophisticated, beautiful apps.

P.S. We really like the idea of isomorphic / universal apps.

Page 13: From 3 to 4 to 5

Too Much Inheritance

Not enough use of mixins, plugins, events, template methods, etc.

Page 14: From 3 to 4 to 5

Monolithic

Forced users into situations they didn't want.

Page 15: From 3 to 4 to 5

Things We Door Want to Do

Page 16: From 3 to 4 to 5

We Do: Static Analysis

With ESLint which allows us to write custom rules.

e.g. we disallow Ext.encode and Ext.decode.

Run linting in C.I. builds when a pull request is made.

Page 17: From 3 to 4 to 5

We Do: Unit Testing

With Mocha and Chai.

Run tests in C.I. builds when a pull request is made.

Page 18: From 3 to 4 to 5

We Do: Aggressive Browser Support• Chrome

• Firefox

• Safari

• Internet Explorer 10+

Page 19: From 3 to 4 to 5

Want / We Do: Separate Deployables

Deploy JavaScript, CSS & Single Page Apps to S3 + Akamai.

Deploy server-side apps & service implementations to data center (Rackspace, AWS, etc.).

Simplifies deployment and enables deployables to evolve (more) independently of each other.

Page 20: From 3 to 4 to 5

Want / We Do: Tiny Modules

Using Bower and some custom tooling we allow reuse of components at a per-component level.

We're big believers in Node-style thinking re: tiny, reusable modules, e.g. @substack's How I Build Modules.

Page 21: From 3 to 4 to 5

Want: Interop With Other Libraries

None of the products we acquired were written in ExtJS and migrating those apps would be a huge task.

We want to share business logic across those apps and we need solutions that run across those apps.

Ideally that business logic is written using ES6 modules.

BTW, we are writing code using ES6 today.

(Could we write a Babel module transpiler to convert ES6 modules into namespaced Ext modules?)

Page 22: From 3 to 4 to 5

Want: To Not Run Sencha CmdOr for it to be Node-based.

Node simplifies our tooling story and simplifies project setup.

Ideally we just run a couple of npm scripts, e.g.:$ npm install$ npm run build

Page 23: From 3 to 4 to 5

Want: Shared HTML Structure and CSSTo allow visual consistency across front-end technologies.

Page 24: From 3 to 4 to 5

Want: To Not Run CompassThe Ruby dependency, particularly on Windows, is problematic.

Page 25: From 3 to 4 to 5

Want: To Education our DevelopersSo they understand the problems we are solving and how to use the tools we choose to solve those problems.

Page 26: From 3 to 4 to 5

Where Are We Going

Page 27: From 3 to 4 to 5

Our Future is Heterogenous

ExtJS for Xero "Business" (aka Blue Xero) and Xero for Practices (aka Green Xero).

Knockout for Payroll.

React for "shared experiences" (header; notifications; etc).

Other technologies used in products we've acquired (WorkflowMax; Workpapers)

Page 28: From 3 to 4 to 5

Throwaway-ability

Change is constant. Avoid boiling the ocean.

Only about 10% of the UI code written to craft the experience lasted more than a year.

-- Bill Scott at Netflix in 2008

Change has to be easy and fast.Working on smaller, more decoupled things helps here.

Page 29: From 3 to 4 to 5

Which Means

Many single page apps; tiny modules; package management; continuous integration; Node-based tooling; working out ways to share without forcing sharing; shared experiences across a heterogenous tech stack.

Page 30: From 3 to 4 to 5

Advice• Learn the library.

• Understand the problem you're solving.

• Trust your instinct re: code smells.

• Don't fight the framework - Ext is opinionated, that's not a bad thing.

• Ask if your struggles are caused by the tools or your techniques?