A bug is a demonstrable problem that is caused by the code in the repository. Good bug reports are extremely helpful - thank you!
Guidelines for bug reports:
-
☝️ Use the GitHub issue search — check if the issue has already been reported.
-
✌️ Check if the issue has been fixed — try to reproduce it using the latest
master
or development branch in the repository. -
🖖 Isolate the problem — create a reduced test case and a live example.
A good bug report shouldn't leave others needing to chase you up for more information. Please try to be as detailed as possible in your report. What is your environment? What steps will reproduce the issue? What browser(s) and OS experience the problem? What would you expect to be the outcome? All these details will help people to fix any potential bugs.
Example:
Short and descriptive example bug report title
A summary of the issue and the browser/OS environment in which it occurs. If suitable, include the steps required to reproduce the bug.
- This is the first step
- This is the second step
- Further steps, etc.
<url>
- a link to the reduced test caseAny other information you want to share that is relevant to the issue being reported. This might include the lines of code that you have identified as causing the bug, and potential solutions (and your opinions on their merits).
Finally, don't forget to add the bug
label to your issue.
Before creating enhancement suggestions or feature requests, please check this list as you might find out that you don't need to create one. When you are creating an enhancement suggestion
- Please include as many details as possible.
- Use this issue as inspiration
- Include the steps that you imagine you would take if the feature you're requesting existed.
- See the avaliable labels and add the ones that apply. For instance, add the label
enhancement
to your issue anddesign
label if it's a design issue
- Perform a cursory search to see if the enhancement has already been suggested. If it has, add a comment to the existing issue instead of opening a new one.
- Check the change log and closed issues — you might discover that the enhancement is already available.
- Check if you're using the latest version of Chatmosphere
- Check if you can get the desired behavior by changing connection options and jitsi options.
Pull requests are the best way to propose changes to the codebase (we use Github Flow). We actively welcome your pull requests:
- Fork the repo and create your branch from
master
. - In your commits, refer to the issue you are solving with this branch (create an issue if there isn't one)
- If you've added code that should be tested, add tests.
- If you've changed APIs, update the documentation.
- Make sure your code lints.
- Issue that pull request and ask for review!
src
│ App.tsx
│ serverConfig
│
└───assets
│ │ fonts
│ │ svgs
│
└───components
│ │
│ └───common
│ │ └───Buttons
│ │ └───Input
│ │ └───...
│ │
│ └───header
│ └───footer
│ └───room
│ └───...
│
└───pages
│ └───enter
│ └───home
│ └───session
│
└───store
│ │ ConferenceStore.tsx
│ │ ConnectionStore.tsx
│ │ LocalStore.tsx
│ │ LocalStoreLogic.tsx
│
└───stories
└───theme
└───utils
components
common
components
don't have a referance to logic (store) but are only presentational- The rest of the components are the composition of the presentational components and DOM elements. These might use the store objects, but won't have a state within.
pages
are components which contain sub-components to for a page with its all content. There is a page for eachRoute
store:
The app state is centralized inside these store objects; where all the state, logic and dependencies are handled. Therefore all other components are purely presentational. We are using zustand to store the app state and immer to manipulate the state inside the store.- stories