Dexibit Challenge

From Vaadin to React

Goals

  • ​Long term: Vaadin → React (JavaScript) → Ditch Vaadin
  • Able to add new code while modernising/migrating
  • Almanac first, then new kitchen module
  • New UI standards not a priority

Reality (1/3)

  • ​UI code bloated: 2,595 files and 119,051 lines. All Java.
  • Quality control: unit tests, user stories but no QA.
  • Agile, releasing every 2 weeks
  • Vigorous roadmap and forward momentum in the market

Reality (2/3)

  • Currently using Vaadin v7 (older than React itself)
  • From v8 can integrate JS components and connectors 
  • Automated migration tool for v7 to v8
  • Only from v14 can import npm packages

Reality (3/3)

  • Vaadin components in Polymer available on npm
  • Library react-vaadin-component not maintained
  • lit-element package comes closest, offers bi-di comm
  • All of them still require Vaadin and a React wrapper
  • Only possible from v14 onwards

Unknowns

  • Haven't seen your code. Highly coupled?
  • Don't know Vaadin
  • Your backend API (big concern!)
  • Time to migrate to Vaadin v14?
  • Bugs interrupting balancing act

Idea: rewrite all (1/2)

Idea: rewrite all (2/2)

    ﹢not carrying over tech debts
    ﹣not tenable, worry never stop moving forward
    ﹣too expensive to do changes twice
    ﹣no ROI for years

Idea: rewrite by module (1/2)

  1. New standalone project for Almanac only on webpack, React and Redux
  2. Runs alone using same style sheet
  3. Bundle all in one external JS file
  4. Include on Vaadin and mount on right place

Idea: rewrite by module (2/2)

    ﹢modularized approach, less disadvantages 
    ﹣new modules still carry few legacy parts
    ﹣where does common code go?
    ﹣where to bring together all modules in the end?

Idea: marketplace

  1. new project to list payable, single modules
  2. subscriptions
  3. provide common code modules reuse
  4. old product still accessible (locked, separate domain)

Idea: strangler approach (1/2)

Idea: strangler approach (2/2)

    ﹢add value immediately
    ﹢better cost control
    ﹣bloated code base for a while
    ﹣takes a bit more time until we take full advantages

Migration: React in Vaadin? (1/4)

First problem to crack: 
- Vaadin version bump needed?
- how to instantiate React components?
- the change from server- to client-side rendering
- getting values from through API or RPC

Migration: React in Vaadin? (2/4)

a) Stick to Vaadin v7 and figure out hacks for React
1. bundle React code separately
2. add a single script tag for that
3. load it in Vaadin with `@JavaScript`
4. connect with `executeJavaScript`

Migration: React in Vaadin? (3/4)

b) Bump to Vaadin v8, then for each React component
1. write server side JavaScript connectors
2. inherit these from `AbstractJavaScriptComponent`
3. exchange via RPC using @ClientCallable or @Endpoint

See https://vaadin.com/docs/v8/framework/gwt/gwt-javascript.html

Migration: React in Vaadin? (4/4)

c) Bump to Vaadin v14, then enjoy
1. `npm install react`
2. less work with connectors
3. more functions for client-server communication

Migration: hollow React components

  • wrap each Java view into a React component
  • return <null> in the render method
  • copy Java code, translate to JS 1:1
  • put in `componentDidMount` fn
  • keep state management inside
  • https://xebia.com/blog/migrating-to-react-step-by-step/

Migration: UI = fn(state)

  • 2nd migration iteration: break down copied code
  • into states and anything visual to the `render()` fn
  • any states backend isn't interested, keep inside
  • reduce code greatly with functional programming

Migration: reduxify

  • introduce redux and reselect
  • replace JavaScript connectors with API calls in events
  • single source of truth
  • delete Vaadin :)

Final thoughts

  • Problems will happen. Spot mistakes with prototypes.
  • Migrate instable parts first to win time saving bugs
  • Repeat past mistakes? Lessons learnt?
  • Practice sustainable software
  • Recommend a dedicated QA tester