Building Multitenant UI with React Vasanth Krishnamoorthy 

We’ll talk about.. • 3 Pillars of multi tenancy • Challenges • Patterns and Abstractions • Design Principles • Takeaways 

3 Pillars of Multitenancy • UX Variations • Composition - Wrappers and other techniques • Extensions - HOC • Style variations • Styled components, CSS Modules • Text variations • L10N (react-intl) 

Challenges • App structures • Single app (with React and Redux inside the app) • App shell + React and Redux together • What we are aiming for • App shell (import the Redux containers) + • Redux repo (API calls + other business logic – Can be reused with react-native) + • React repo (Dumb components – only cares about Presentation) • Repos are organized based on feature 

Abstractions – Scenario 1 • Login UX variations toggle features + add in additional links/markup. 

Abstractions – Scenario 1 • Composition If the UX variations are involve toggling features within a component + adding minor markup around it. 

Composition • Combining smaller reusable components to build a bigger UI blocks. • How do we make sure components are reusable? • By ensuring our UI components are pure presentational components (dumb) • What does reusable mean? • No data fetching within the component (do it in Redux). • If data is required from API - goes into Redux • Via redux-thunk API calls are isolated away from the redux containers that deal with the data obtained and pass it on to the dumb component. • If we have a bunch of renderBla() functions within the component which are used in the main component render() --- It’s better to move it to separate components. That way it is reusable. 

Abstractions – Scenario 2 • Minor UX variations in the component to toggle features ON/OFF. • Like showHidePassword feature for a Password field. • Modify the component to take in a prop to control it’s behavior. • Gotcha: Easy to overuse this idea by adding props for every variation. Only add in props for features specific to the current feature that the component. Basically, not violate the Single Responsibility Principle. 

Single Responsibility Principle • In React • Components/Containers code must essentially deal with only one chunk of the UI feature/functionality. • Eg. • Address container (Only has address related fields) • Name container (first and last name) • Phone component • State, City and Zip code container • In Redux • All API related call go into Redux thunks • The thunks are responsible only for the dispatching action on AJAX begin/fail and complete. • Any routing has to be dealt with the receiving component via a promise. 

Learnings – Keep It Simple Stupid (KISS) • Essentially, if the component needs no state - use stateless functions. • Perf matters: Stateless fns > ES6 class components > React.createClass() • Don’t pass any more props than required {...this.props} only if the list is big -- if not pass individual props. • Too much flows of control (If-else variations) inside the component is usually a red-flag. This most likely means - need to split up the component or create a separate variation. • Don’t optimize prematurely - We are not going to create components that work with all variations all at one. Make the current component reusable with current products that use it. As long as components are without side effects and do only one thing - they can eventually be worked upon by future apps easily. 

Abstractions – Scenario 3 • Higher Order Components • Just a fn/component that wraps and returns another component. • Example: Toggling features On/Off 

Abstraction – Scenario 4 • Higher Order Component - Props proxy • Basically helps to add/edit props passed to the Component. • We could possibly use this for L10N too? 

Abstraction – Scenario 5 • Example 3: Adding tracking across various components. • Helps to keep it DRY (Do not Repeat Yourself) • Removing tracking logic etc. from the component itself makes it testable as well, which is key. 

Abstraction – Scenario 6 • Handling Wrapper

Abstraction – Scenario 7 • Displays items in different order. • Use a prop to specify order – Map through ReactElements and render it based on order prop. 

Takeaways 5 qns to ask while making components reusable. • Does this component deal with one and only one feature? • Single Responsibility Principle – Favors composition. • Does it have any side effects? • If so, isolate it. • Am I reusing code? • If repeating -- is it absolutely necessary? • Am I over optimizing for too many use cases? • If so, relook. Make it simpler – Don’t optimize prematurely. • Is my code readable? • Too much clever code, defeats readability. 

Any Questions? Thank You J