pos rearchitecture

POS Re-architecture in React/ Redux

Why Re-architecture done?

Legacy POS Front-end

Problems• Poor code maintainability and scalability• Poor functional programming• Service class implementation

• Business logic and repository calls fallen under same • Singleton pattern

• JS unit test implementation• Lack of performance• Offline

• Failure to add new files into the appcache causes system break while offline mode

CINCO Re-architecture

Technology Stack


Design Principles


Design Principles• UI Components

• Stateless react component• Pure function whose HTML output is entirely depends on the input• Input, NumberInput, Button, TouchButton etc.

• Business logic• Models – definition of data structure• Managers – stateless functions that accept data structures, perform

business logic and output data structures• Repositories – classes used to access data that exist outside the

application• Application state

• Single source of application state where all data that needs must only be stored – Redux store

• Reactive view• No direct DOM manipulation• UI components are directly connected to data in the store in a way that

updating data in store will automatically update any views that are displaying those data

• Modularity• Collection of UI components, actions, reducer, data (specific part of store)

and handlers• Modules may only interact with each other by sending and receiving

actions


Design Principles contd.• Action based workflow

• Any user interaction results in an action• Action is a function which accepts parameter (payload), perform some

logic and output an object and emit its event (private or public event).• Output object is received by store (reducer) and change the specific value

in store• Actions are promissory

• Public and Private actions/ events• Private – intra communication• Public – inter communication


Module Architecture


Architecture


What we have uniquely done• Handlers

• Action -> Reducer -> Handler• Handler can dispatch an action (private/ public)• Handlers have read-only access to all states• Navigation should be handled by own module’s handler

• Interrupts• Used when navigating in between routes• For an example when moving out order edit screen (order edit -> order

queue) then remind the user to send items to kitchen

• Front-end code is build as a OS package• No need to download the front-end files• No need to worry about offline

• De-coupled modules


What did we learnComparison with legacy POS• Proper framework will reduce development time

Things we would have done better• Could have not used the public and private actions/ events

• Public events are on bus• Even though a module is not required to listen for event still it has

access for it• Instead of public/ private concepts we could have implement

subscription mechanism

• Differentiate app state and UI state• All the states are available in single state• Some state values are not required for UI components

pos rearchitecture

Software