GitLab

List of components taken from this doc: http://bit.ly/2QC4NqL

• Platform
• UI framework #2 (closed)
• Component library / style guide
• Grid system / Flexbox
• Styling
• Reusable Logic
• Types? prop-types? Flow? TypeScript?
• State
• Routing
• Functional rather than Classes?
• GraphQL library
• Document dev environment

Platform: React (Web)

• We first considered using ReactXP, a "library for cross-platform app development" developed and maintained by Microsoft. It is used in production for Skype. Good to know: "ReactXP is not its own framework, it wraps react-dom and react-native into one common API/UI set".
• We looked at reactxp-shop as an example of a ReactXP application which uses GraphQL. We can use it as a point of reference for how to incorporate the chosen technologies into a ReactXP application.
• We created a "hello world" ReactXP application, the first incarnation of which can be found here.
• When we went looking for UI frameworks / component libraries, we found none compatible with ReactXP, and realised that ReactXP compared to React Native Web seems to cater to the lowest common denominator, as it "exposes only those props, style attributes, and APIs that are available across all platforms" and it has a conservative stance to evolution/innovation, as "small breaking changes to the ReactXP interface are painful for the Skype team because we've built over 300K lines of app code on top of the library". Given these points, we then thought to use React Native Web.
• We later reconsidered our assumption that going fully cross-platform from the start would save development time/effort and decided that building a web-only app (still responsive so it can be used on mobile) would be faster and more flexible, at least for the MVP. So we're simply using React (Web).

UI framework / component library: styled-components and Zendesk Garden

• We looked Native Base, which supports both React Native and React Native Web.
• After deciding to start by building for Web only (see above) we created a spreadsheet of React component libraries available.
• We chose styled-components and the modular Zendesk Garden as a foundational UI toolkit, which we'll be able to extend, or pull in other components from any styled-components based toolkits. Garden has a bootstrap-based flexbox grid system.

Types

We're using TypeScript, compiled with Webpack.

GraphQL library: Apollo

• We decided to use Apollo as this has a suite of React libraries to connect the app to the backend GraphQL DB.
• We need to check what's best approach to using the Apollo client, if we can seamlessly use the React client on web and the Apollo native clients on Android/iOS. Mayel is asking the Apollo team for advice/experiences with this approach.

State

• The obvious options are React or MobX. However as we are using the Apollo client to interface with the GraphQL back end, we have looked at apollo-link-state, which allows an application to store local data in an in-memory GraphQL cache.
• We have decided to use apollo-link-state for the client state, as it means we are dealing with only one language for querying both the server and client states.

Routing

• React Router is the defacto React routing library, and is very well documented. There are no strong alternatives so we will use React router for the client.

Functional / classes

• We will use the function or class component approach where appropriate for the component in question. For example, for presentational components the "pure" function component should be used and the component only upgraded to a class when it meets the criteria of a "container" outlined in this article.