Skip to content

Latest commit

 

History

History
179 lines (141 loc) · 6.93 KB

CONTRIBUTING.md

File metadata and controls

179 lines (141 loc) · 6.93 KB
Raw

🤝 Contributing

Thank you for considering and taking the time to contribute! 💖

Working on your first Pull Request? You can learn how from this free series How to Contribute to an Open Source Project on GitHub

The following are guidelines for contributing to this project.

  1. Fork and clone the repo.

  2. Create a branch for your PR with git checkout -b your-branch-name

Tip: Keep your master branch pointing at the original repository and make pull requests from branches on your fork. To do this, run:

git remote add upstream https://github.com/Blocship/star_book.git
git fetch upstream
git branch --set-upstream-to=upstream/master master

This will add the original repository as a "remote" called "upstream," Then fetch the git information from that remote, then set your local master branch to use the upstream master branch whenever you run git pull. Then you can make all of your pull request branches based on this master branch. Whenever you want to update your version of master, do a regular git pull.

  1. Open Issue, discuss what you are planning to do.

  2. Make changes and create Pull Request.

Code GuideLines

  • Put widget in shared folder if the widget is shared between 2 or more screens.
  • Make a class _Private if it is not shared or does not needed to be exposed for other classes
  • Prefer const over final for variables.
  • Prefer to create const constructors for immutable classes.
  • Keep the code loosely coupled and highly cohesive.
  • Never use dependencies directly in the widgets, prefer to create a service class and use it in the widget.
  • Annotate with @override for all the methods that are overridden from the super class.
  • Never leave the data types as dynamic or Object.
  • Use OOP concepts for code organization and reuse.
  • Prefer named parameters over positional parameters.
  • (Optional) Prefer relative-import over absolute-import for (our own) file imports. Use absolute-import for importing from the packages. This extension might help you with this.
  • Use snake case for file names.
  • The filename should correspond to the name of the primary class in the file.
  • Names of files that contains widgets that take the whole screen should end with the suffix: _screen.dart, for example, signup or login takes up the whole screen for authentication.
  • Use Camel Case convention for class and enum names.
  • Name (classes, variables, functions, modules) in a meaningful name which describe its functionality.
  • Make sure that all .dart files are formatted using flutter format command.

Read more from linting here: https://dart.dev/guides/language/effective-dart/style

Architecture Diagram

                                       +-----------------+
                                       |                 |
+------+  Events  +------+  Request    |                 |
|      +--------->|      +------------>|                 |
|  UI  |          | Bloc |             |   Repository    |
|      <----------+      <-------------+                 |
+------+  States  +------+  Response   |                 |
                                       |                 |
                                       +-------^-----+---+
                                               |     |
                                      Response |     |  Request
                                               |     |
                                       +-------+-----v--+
                                       |                |
                             Class     | +------------+ |
                  +-------+  Object    | |API Provider| |
                  |       +----------->| +------------+ |
                  | Model |            |                |
                  |       <------------+   +--------+   |
                  +-------+   Json     |   |Local DB|   |
                                       |   +--------+   |
                                       |                |
                                       +----------------+

Directory Structure

lib
├── data
│   ├── data_source
│   ├── models
│   ├── repository
|   └── utils
├── domain
│   ├── models
|   └── repository
├── presentation
│   ├── service
│   ├── shared
│   ├── theme
│   ├── utils
|   └── screen
└── main.dart

Routes

routes
├── / (SplashScreen)
├── /intro (IntroScreen)
├── /main (MainScreen)
│   ├── /main/year?year=2023 (YearScreen)
│   │   └── /main/year/month?year=2023&month=4 (HomeScreen)
│   └── /main/profile (ProfileScreen)
│       ├── /main/profile/analytics (AnalyticsScreen)
│       └── /main/profile/settings (SettingsScreen)
│           └── /main/profile/settings/license (LicenseAgreementScreen) 
├── /journal?date=2023-01-01 (JournalsListScreen)
│   ├── /journal/new?date=2023-01-01 (JournalCreateScreen)
│   └── /journal/:id (JournalDetailScreen)
│       └── /journal/:id/edit (EditJournalScreen)

Git Tagging and Releases

To automate deployment using Github releases, follow these steps:

  • Create a git tag:

    git tag -a v1.0.0 -m "Release version 1.0.0"

  • Push the tag to GitHub:

    git push origin v1.0.0

  • Create GitHub release:

    • Go to Releases section in your repository

    • Click on Create a new release

    • Select the tag you want to release and add notes

    • Finally, click on Publish release

🐛 How to Report Bugs

Please open a new issue including steps to reproduce the problem you're experiencing.

Be sure to include as much information including screenshots, text output, and both your expected and actual results.

🙏 Help needed

Please checkout the issues and project board


Thanks ✨

Acknowledgements

Websites that helped me in making this project through out.