Contribution Guide (@copyright by hyochan)
We prefer you to use vscode
Commit messages should include a title, summary, and test plan.
Write the title in the imperative mood and prefix it with a tag that describes the affected code, like [android] or [video], and makes it easier to read through the commit log.
In the summary, explain the motivation behind the commit ("why") and the approach it takes ("how"). Note things that aren't communicated by the code or require more context to infer.
Use the test plan to communicate how to verify the code actually works and to help others in the future create their test plans for the same area of the codebase.
This post called How to Write a Git Commit Message has a lot of good guidance, too.
- Please search and register if you already have the issue you want to create. If you have a similar issue, you can add additional comments.
- Please write a problem or suggestion in the issue. Never include more than one item in an issue.
- Please be as detailed and concise as possible. * If necessary, please take a screenshot and upload an image.
PR is available to main
branch.
Each PR should correspond to one idea and implement it coherently. This idea may be a feature that spans several parts of the codebase. For example, changing an API may include changes to the Android, iOS, and web implementations, the JavaScript SDK, and the docs for the API.
Generally, each PR should contain one commit that is amended as you address code review feedback. Each commit should be meaningful and make sense on its own. Similarly, it should be easy to revert each commit. This keeps the commit history easier to read when people are working on this code or searching for a commit that could have broken something.
Please follow the Coding conventions as much as possible when contributing your code. This is mostly covered by eslint
plugin in vscode
. Add eslint
plugin and add below in setting.json
in vscode
to fix coding style
in live editing.
{
"eslint.validate": [
"javascript",
"javascriptreact",
"typescript",
"typescriptreact"
],
"editor.codeActionsOnSave": {
"source.fixAll": true
},
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[javascriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"javascript.preferences.importModuleSpecifier": "relative",
"typescript.preferences.importModuleSpecifier": "relative",
"prettier.configPath": ".prettierrc.js"
}
npm run lint
command will cover your code style either.
General styles
-
The indent tab is two spaces.
-
The class declaration and the
{}
in curly brackets such as function, if, foreach, for, and while should be in the following format. Also if you installed eslint in vscode or in your code editor, it will help you with linting. *{
should be placed in same line and}
should be placed in next line.for (let i = 0; i < 10; i++) { ... } array.forEach((e) => { ... });
-
Space before
(
and after)
.
*** Important ***
-
testID should be written in
kebab-case
testID = "my-test-id"
-
Class name should be a
PascalCase
-
Enum type should be a
PascalCase
-
Constants should be written in
UPPER_SNAKE_CASE
- Note that this is for
number
,string
and constantarray
. - Unformed data type like object or class variable should be written in
camelCase
.
- Note that this is for
-
Variables and functions should be written in
camelCase
-
Assets name should be written in
lower_snake_case
const imgUrl = 'assets/icons/icon_add.png'
-
If you find code that does not fit in the coding convention, do not ever try to fix code that is not related to your purpose.
-
while you are using prettier extension, you may encounter ternary operator indentation problems
you can use
// prettier-ignore
like below
Hackatalk uses Jest to write test codes for both client & server.
Client test codes are written with @testing-library/react-native
.
If you are not familiar with the library, check out its documentation.
Also, Kent Dodds has a really good article about what to avoid when writing tests for React. Here are a few rules especially important in Hackatalk test codes.
-
Use explicit assertion for
waitFor
:waitFor
retries an assertion until it passes or until timeout. Therefore, an emptywaitFor
call does nothing but run one tick of the event loop. Put single explicit assertion insidewaitFor
.// Wrong. await waitFor(() => {}); // Correct. await waitFor(() => screen.getByText('Complete')); await waitFor(() => expect(mockFunction).toHaveBeenCalledTimes(1));
-
Use
act
only when necessary:render
andfireEvent
is already wrapped insideact
. Do not wrap them again. Also, do notawait
theact
call becauseact
is not an async function.// Wrong. act(() => { fireEvent.press(sendButton); }); // Correct. fireEvent.press(sendButton); act(() => { ... });