RD Flex Style Guide Issues To Be Voted On

README.md

RD Flex Style Guide Issues To Be Voted On

Feel free to add to this as you see fit and make suggestions, I think anyone can commit to this gist if I'm not mistaken, or at very least quote it and comment on it.

This is still a work-in-progress. I plan to provide brief pros/cons foreach item in the final variation, as well as organize things a little better into common sections.

Right now I'm thinking we will just vote on these issues using a plain old google form, that way I know we will be able to reference the results within our documentation, but even our voting mechanism is up for debate at this point.

VoteOn.md

Vote on:

Process of Making Changes/Constitution

Constitution defining how we make changes to our style guide and defining voting rights/how much each vote is worth/who shall have the right to vote/the process by which we make changes/propose changes/object to changes—all with a historical record. Defining who is eligible to vote on any given item.

StyledPrefix

• Everywhere
• Only in some cases
• Etc

Object-path-immutable

• everywhere,
• everywhere in reducers,
• everywhere in selectors,
• only when dealing with complex reducers,
• only when dealing with complex selectors,
• etc

Style guide/Guidelines

When we should use a service When we should use useApi When we should use Twilio’s Actions api When it's acceptable to use dom manipulation

DynamicForm{Component} -> suffix all non-redux connected components with the name {Component} Component export conventions in general. Should we export mapStateToProps for instance? (For testing) what about component props? What’s the standard?

Testing

When should tests be required?

Standardize test structure either by creating test helpers or documentation or both. Decide on the exact test standard.

Enzyme vs @testing-library/react Unit testing vs integration testing vs end-to-end testing? Code coverage thresholds Cypress, storybook, or both?

When do we write tests. Or when is it acceptable not to write tests is probably a better way to phrase it.

Dependency injection/inversion of control?

Development

Should we develop with render painting turned on

When do we reuse stuff When do we abstract stuff out

Redux

Redux questions. What should our guidelines be in terms of how we should structure our redux. When we should use redux, etc?

When should we store something to redux?

Redux architecture to optimize rendering

Rendering

When is it not acceptable to use useState()

Hooks Guidelines

When is it acceptable to create a custom hook?

Ticket Handling/Pull Requests

When do we close tickets

When is it acceptable to create your own tickets

How strict should we be on pull requests exactly? What are the steps we should take during each review? What is expected of the reviewers exactly? Acceptable timeframe for review?

How do we assign tickets exactly? If there are tickets left unassigned, how does one know whether that ticket is an appropriate ticket for them to work or not, etc?

How do we even the playing field in terms of tickets and points and hard tickets that go way over?

How do we do release comments/aggregate closed tickets for QA? (Semantic release each feature perhaps for nick and QA? Or a custom jira issue filter perhaps? Etc.)

How should we do release notes exactly? Should we have everyone learn semantic release so that way all our main features are documented in each release by the person who actually coded them? Should we make ppl get in the habit of formatting their commit messages a certain way? (Either on occasion when necessary or always) Etc.

How do we know when a ticket is complete? Who is authorized to make that judgement?

What’s the process of moving a ticket to complete?

When is it appropriate for myles to review Ines pull requests?

Code Generation/Consistency

Should we have shared snippets? Should we have code generation capabilities that are shared and accessible to the whole team?

Documentation

Are docs required?

When should docs be required?

Documentation engine

Documentation questions. Do we like docusaurus? Or would we prefer something like Gatsby which has a backend controlled by graphql instead? Or perhaps we just continue with plain old readme’s or notion.

When Documentation Should Be Required Guidelines

What is considered acceptable documentation for any given feature we deem requires documentation?

Should we keep our documentation close to our code, (i.e. auto-generate using something like typedoc) Or should we strive for more personal written documentation like markdown files? Or a combination of both? Etc.

Twilio Integration

When to reuse twilio components exactly? What is our end game in terms of working with twilio? Stay coupled to them or not?

At what point do we derive data? Like say we need a personId, which can be looked up by leadId or residentId but it’s not being passed in from webchat. And others will also likely need personId. Do we change the webchat to pass it in early in the lifecycle of the task, or do we do it in the search so at least that way not everyone has to re-query the exact same thing? When do we do one vs the other?

How to best handle different communication channels on a high level? Like how should we structure our code in this case? Should we use generics? Factory maybe? Should we structure our files a certain way consistently throughout different component hierarchies to make it easy to always be able to find what you are looking for when working a certain communication type? Etc.

Code Structuring/Naming Conventions

Structure of code on high level in general. Do we allow more than one thing per file for instance? If so, when?

Naming of different types of models (i.e. export interface SearchExecuteParams { } vs SearchExecuteResult vs SearchRedux vs PreSearch vs SearchApi ) It would be nice to have a standard naming convention for backend api request param typings/models, (like prefix/suffix on all types of that nature) in addition to a standard naming convention for say the backend api response typings/models, etc, etc.

File structure/naming. When to capitalize file name? When to camel case? When to kebab-case our file names? (Use hyphens) How to know where to put things exactly? Based on component need hierarchy? Based on what you are dealing with?

Guidelines for New Communication Types/Task Types

Contact email, contact call, contact reason still need to be wired up on submission.

“End email” conversation btn/action on task router still needed, just like “end chat” and “end call”. (We need to go through the process and do it all right using a new channel definition and whatnot, (twilio.com/docs/flex/developer/ui/task-channel-definitions) which is what I honestly planned to do once I finally get to the following issue(s): https://rentdynamics.atlassian.net/browse/HCC-480?atlOrigin=eyJpIjoiMGY2NmYzZDVmZjUwNGUwZmIxNTlkYjE1OWMwMDI2ZTQiLCJwIjoiaiJ9 | https://rentdynamics.atlassian.net/browse/HCC-485?atlOrigin=eyJpIjoiOTg1MmE0NzVlNTM4NDM1Mjg3Y2I5YTNmZTFlODQ1MTciLCJwIjoiaiJ9

General pair programming guidelines for new features.

Do we allow any one person to take complete control over an entire feature or should we make sure there are always multiple people involved, just as a general guideline?

When do we assume it’d be best for logic to be done on backend as opposed to the frontend? (In situations where it could really be done either way)

Typings/Eslint

When do we do typings? Or maybe a better way to put it, when is it acceptable to not do typings?

What should our eslint rules be?

Development tools/Deployment

Monorepo/micro-frontend architecture or not?

Releases

Should we have feature releases?

Private Libraries

When do we add a new private library - after code has already been duplicated once? twice? Only when it’s going to be used across projects? Or just when we know it’ll be used frequently? Etc.

Voting

Voting engine - how should we handle voting on our conventions exactly?

Errors/Warnings

When is it acceptable to have console erros/warnings? What is the process by which we will fix them later if it is deemed acceptable? Do we even need to fix them later or are we just not going to worry about them? Etc. When is it acceptable to have console logs in your code?

Backend

When do we do restful vs non restful api backend endpoints?

How do we know who is responsible for the backend on any given feature?