These are the areas I plan to touch on: Overview of Jira’s journey towards a modern, React-based tech stack: Timeline - where did we start, where are we now; from lipsticking, to an inside-out model, to an outside-in model. A primer on web performance at Atlassian: Vertical vs. horizontal scaling; TTR vs. TTI; P50, P90, APDEX. Server Side Rendering (SSR): How it works and why it works; the security implications of SSR; Atlassian’s patented SSR architecture. Single Page Application (SPA) architectures: Full page load vs. SPA transitions; the “network effect” of an SPA and its implications; how to integrate legacy experiences into a fundamentally modern SPA. Education and alignment: How can independent teams and engineers sustainably use a shared, limited resource such as the browser? Up next: What are the upcoming trends and technologies that Atlassian is looking into?

Outline What is accessibility General accessibility Web accessibility Why we did it(Making HackerRank websites accessible) Business reasons UX improvement Inclusion/Increase in user base(more people can user our site) Corporate Social Responsibility More enterprise customer(some customer requires product accessibility compliance in contract) Legal reasons(accessibility compliance laws in various countries, latest Apple and Dominos fiasco) Others(Empathy, WCAG, ATAG) How we did it Updating existing reusable UI components(will have examples of few major components with code and demo) Custom components specific to accessibility(HOC to detect keyboard navigation with code and demo) Showing minimum contrast pass/fail on internal colour library(code and demo) Setting up Unit testing(code and examples) Setting up Dev tools warning(code and demo) Dark mode.(Strategy/code and demo, and screenshots of feature requests from visually impaired users) eslint-plugin-jsx-a11y to catch issues while coding(screenshots/demo) ChromeVox/VoiceOver for screen reader testing(demo) What’s next/We’re still doing it Accessibility is a process and not a project. Integrating reach router functionality with react router 5 CI/CD integration. Impact Positive and exciting feedback from users on dark mode and on user experience. As of now, there is no way to track screenreader users or distinguish different users with disabilities from the rest. Idea of web accessibility is to remove discrimination from web and any attempt towards that helps the cause. Levelling the field for candidates as now they don’t need to disclose their disability and ask for special treatment. We are closer to make our site accessible for everyone which removes the dependency from customer support team.

The Idea. Why Brahmos? How did it start? Improvement on React library itself? Use lit-html as templating engine? What it is trying to achieve? How does it work? How react rendering works? How Brahmos optimizes it? How does rendering work on Brahmos? Working Example Todo MVC built with Brahmos (Demo) Writing Components in Brahmos Current state Available React API Pending features Future path How progressively Brahmos will be developed. Maintaining the developer experience. 3rd Party React component support.

For any modern stack that revolves around React/Vue/Elm or likewise libraries, we usually go ahead and use Redux for state management. It works well, it’s just aesthetics may always be improved. What we try to cover here is how to build your store architecture around Redux so that for every part of the state you need to define, you don’t have to create a reducer from scratch. Instead how about just providing the config and something else do the magic for you ;) At Mindtickle we use a common Redux store across multiple applications. It has done good at easing our lives, and that we think is worth sharing with the community. Manage your complex sync/async flows just by passing a simple config. Handling scoped states becomes a breeze, as it is just another config. Have same method of handling scoped state also enables us to standardise read and manipulation operations over the same. Standardization of flow management by creating common reducer pattern for teams For every new person joining the team, he/she needs to understand just the reducer generator logic once. No more going to each reducer file and understanding the same. Keeping your app performant with such patterns. We got to a state to get reducers created by just providing corresponding config. This enables us to write just one reducer generator throughout the application. For every reducer needed in the application, developer just needs to provide a config and the rest is automatically taken care of. How this helps with above issues- For every part of state doing the same thing, logic need not be repeated in reducers for corresponding states. Handling scoped states becomes a breeze, as it is just another config. Have the same method of handling scoped state also enables us to standardise read and manipulation operations over the same.

Why React and Redux ? - Declarative vs Imperative - JSX for templating - One way data binding - Virtual DOM for faster rendering - Simple, scalable and fast - Redux : 3 principles - Single source of truth - Pure Functions - State is read only - Redux: An example of command pattern React optimizations and performance improvements: key takeaways - Usage of PureComponents instead of Component for faster performance through shallow comparison - Pass only what is needed in props to avoid unnecessary rendering and scripting - In connect, pass only what is needed in mapStateToProps - Render only the components needed - Use memoized selector (reselect) for faster data manipulation Error Handling - Integrate Sentry with tool - Maintain ErrorBoundary and keep it as granular as possible Development - Break components into sub components and keep it modular - Ensure to make the components reusable enough by passing generic props and setting default values for props - Use only one UI framework eg: ant, semantic - Ensure to add a README.md in code for new developers Error State -Never setState within render to avoid infinite rendering -Never setState within componentDidUpate without checking that prop or state is actually changed

The talk will be broken down in the following: Why state management is required? Brief intro of redux. Benefits of redux. (Single source of truth, time travel debugging?) Problems with redux. (Too much boilerplate code, learning curve, etc) When to use the Context API instead of redux. How to scale the Context API using hooks. Bonus topic: Typescript for speeding up the development.

The session will consist of 1. What Micro Frontends architecture is in brief 2. Problem that we are trying to solve with this Architecture 3. What are the constraints that need to be adhered to 4. Deep dive into the Fitment widget and the design it uses 5. Design Elements and Details of this implementation 6. Q&A at the end of the sssion

How we introduced React in monolithic architecture 1.Performance 2.Integration 3.Collaboration 4.Handshake 5.Flighting How we create sharable architecture 1.Webpack 2.Appchrome with nugget cache 3.Typescript and script sharp similarity 4.Reduced js size. Telmetry and performance logging 1.Logging que implementation 2.Component level logging. React with Tensorflow 1.A glimpse towards Machine learning under the hood of react.

Introduction to Data-Driven apps How to Elasticsearch Introduction to ReactiveSearch A demo app with explanation ReactiveSearch Architecture ReactiveSearch Ecosystem (Maps, Vue & React-Native) Q&A

Problems faced using REST and their solutions Mocking: During development the most common problem faced is mocking. Generally frontend(app/web or both) is blocked on backend due to unstable apis or breach of contract with the backend. Mocking is implemented in frontend to overcome this problem but different implementation is needed in both app and web to achieve mocking. Still there is a limitation that you have to mock entire APIs. With graphql you can achieve seamless mocking for both app and web and its as simple as writing “@mock” Backend-Frontend Coupling: Generally frontend objects are coupled with backend schema. If the schema changes, the api structure changes, hence the frontend changes unnecessarily. With graphql, things become decoupled between frontend and backend. Graphql defines a schema which is consumed by the frontend. The objects are resolved using resolvers written in the server. When the schema changes, only the resolvers change, but there is no need for the schema to change. The eternal and relentless fight between frontend demands and backend supplies: Multiple and sometimes serial calls are needed to render a page in frontend and these calls over internet take a lot of time. Graphql combines these calls returns a neat object to frontend Overfetching: Read only the data that you require. Breach of contract: How many times have you sent a build and the API calls failed as some you made a typo in the request. Graphql locks the schema and provides static type checking. Eslint graphql plugin validates the schema for you. Autocomplete in queries is also possible by using relevant plugins. True Componentization of React Components Things needed to render a component? HTML, style(CSS) and data React brought in the component pattern and HTML. CSS in JS brought in style componentization. The component now owns the style. What about data? Component defines the data it requires to render using fragments. A wrapper translates the data into a graphql query and supplies the data to the component Feature Enablement We follow trunk based development. So lots of features are in the master branch and they all get pushed to staging/production etc. Someway needed to disable the features. Disabled features should also not bring their data. Possible easily with the “@skip” directive Declarative way of implementing things Deferring an object Skipping an object Declarative queries and mutations