2. Data-driven development
- Testing
- Linting (Syntax)
- Unit Tests (Logic)
- Integration (Business Logic)
- Business logic as first-class citizen
- Most of an application’s bugs are due to business logic
- Unit tests can only enforce application logic
- Especially tough when there is frontend separation from
backend (Runtime errors)
3. Static typing
• Pros
• Self-documenting code
• Static typing as tests
• Cons
• Time taken to learn
• 80/20 rule
• Tooling
• IDE support
- Briefly explain that data-driven development means enforcing business logic in the code
- 80/20 rule? Get most of application functioning with basic features
- No need for extra fluff like tuples, generics at the start
- IDE support (VSCode has first-class support for Typescript, Atom has first-class support for Flow)
- Personally I went with VSCode for editor, Flow was added as an afterthought
1. See how many ppl play poke go in the audience
If a lot - great, familiar
If not many - also great - won’t be familiar with business logic, but flow will enforce that
2. Show app, built with create-react-app and 2 libraries - lodash and flow-bin
3. Show the relevant components - Gym and GymContainer
4. For Gym, explain simple flow annotations. Also show local.flow.js
5. For GymContainer, mention it is a HOC data component + basic explanation of what it does
6. Show index.js, just mounting the GymContainer with existing data
7. Start with mounting the app - yarn start - an error should show.
8. Also run yarn flow
9. Fix flow errors
- scalable
- intellisense
- flow-typed
GraphQL is an order of magnitude harder in difficulty compared to plain Flow
Backend revamp, requires lots of effort
But if you can spare the effort, benefit is worth it
- Show generated output - graphql-export.flow.js
- Elaborate on when the server schema changes, they can be propagated to the front-end with ease as well.
- Show SampleQuery.graphql
- Show generated output - schema.flow.js