Brief | V1 Problems | V2 Scope | V2 Tech Stack | V2 UX
- Monolithic components
- Monolithic hooks
- Environment variable explosion
- Disparate OAuth flows
- CLI version combined with UI version
- Hard to read and maintain
- Deeply custom:
- Divs all the way down,
- Strewn with hundreds of css classes
- Make a kit of small, reusable components that are already styled for use anywhere in the app
- Easier to reason about than inline-customized primitives
- Minimize css for inline customization
- Only pass state
- Define functions to use as handlers rather than writing inline in code
- Makes component instantiation markup smaller and easier to understand
- Separates code from markup
- E.g.,
useConnectionis nearly 1k lines long
- Extract inline logic out to function libraries / classes that are easier to reason about and test in isolation
- We have a configuration file but it is for servers, not things like request timeouts, etc
- The addition of a new environment variable for everything someone wants to configure is problematic.
- It’s easy to misspell the variable name and the names
- Often not named in the best way
- Lots of touch points to update for a new variable
- A JSON configuration file would be a better approach.
- Hierarchical groups of settings could be used
- Different files for different configurations
- Expanding the format to include other settings
- A configuration file could be validated, so misspelled keys would be caught at startup
- We often have deviations of behavior between basic flow, quick flow, and guided flow
- Each flow has independent code paths that can break or behave differently from the others
- Use a single auth flow mechanism that operates in all three states while supporting different configurations
- Both projects are not kept in parity and do not share significant overlap as to belong in the same repo
- Refactor/extract the CLI Inspector to a separate repo for ongoing development