We love your input. You can contribute to this project in many ways like,
- Raise an issue or bug
- Prapose or Create a new feature
- Improve the documentation
- Submitting a fix
Pull requests are the best way to prapose any changes to the existing code or documentation. We actively welcome your pull requests.
- Fork and clone the repo
- Move to the branch you want to work
- After doing all changes, submit a PR and ask for review.
- Don't directly work in master branch, instead work in separate branch according to changes you want to prapose.
In ToolPool, tools are divided among various categories.
- If you want to prapose a whole new category/tool in ToolPool, first raise an issue for it from category-request and tool-request respectively.
- Once everything is discussed and the category/tool is approved, we'll provide a new logo for category/tool
- Then you can start working/coding on it.
How to add new category in existing list?
- Create a new branch with
{categoryname}
(ex. texttools) from master - Move to
.\static\utils\config.js
- In
config
map variable, find thecategoryList
and add the new category details (name, logo, id (must be in camelCase), key (increment according to last category in list) ) at the end according to below format.
{
name: "{CATEGORYNAME}",
logo: "ADD ANY LOGO FOR JUST TESTING PURPOSE, WE'LL UPDATE THIS LATER",
id: "{CATEGORYNAME} in camelCase",
key:{INCREMENT ACCORDING TO LAST CATEGORY IN LIST}
}
- In same
config
map, at the end add a key-value pair with key as Category name in camelCase and a list as value which will contain details of tools of that category.(see other category listed in map) - After that move to
.\components\Tools\
- Create a new folder with category name in TitleCase
- Inside that folder you can create folders for new tools
Note: New category will get listed in master
only after at least one tool is there(in working condition) for that category
How to add new tool in existing category?
-
Shift to category specific branch
-
Move to
.\static\utils\config.js
-
In same
config
map, find the category key-value pair. -
In that list of tools for that category, add details of the new tool.
-
Format of details,
{ title:"{TOOLNAME}", desc:"{TOOL DESCRIPTION}", link:"tools/{CATEGORYNAME}/{TOOLNAME}", icon: "ADD ANY LOGO FOR JUST TESTING PURPOSE, WE'LL UPDATE THIS LATER", key:{INCREMENT ACCORDING TO LAST TOOL IN THAT CATEGORY} }
-
After that move to
.\components\Tools\{CATEGORYFOLDER}
-
Create a new folder with tool name in TitleCase
-
Inside that folder you can code your tool
-
Move to
.static\utils\toolDescription\toolReadmes.js
-
Create a new variable for your tool and provide detailed information in
markdown
format. -
Now, move to
.\static\utils\toolComponentsList.js
-
In
TOOLS
map, go to the desired category and a key-value pair for your new tool details in below format."{toolname}": { title: "{TOOLNAME}", component: <TOOLCOMPONENT />, url: "{CATEGORY}/{TOOLNAME}", description: "{1-LINE DESCRIPTION}.", icon: "ADD ANY LOGO FOR JUST TESTING PURPOSE, WE'LL UPDATE THIS LATER", readme: {README VARIABLE FOR YOUR TOOL}, poster: "ADD ANY LINK FOR JUST TESTING PURPOSE, WE'LL UPDATE THIS LATER", },
You can see other tools for reference
Styling in Toolpool
To start with, the styles directory holds most of the properties of the design system. You can find common queries regarding the usage of the style system below.
-
How to access colors based on Theme?
-
How to access styles of different custom components?
-
To access styles of commanly used custom components, checkout styles/mixins.js To access components, use this syntax
${({ theme }) => theme.mixins.smallButton};
Add custom styles which are going to be used widely in the project in mixins.js file.
-
In short, when you submit changes, your submissions are understood to be under the same MIT License that covers the project. Feel free to contact the maintainers if that's a concern.
We use GitHub issues to track public bugs. Report a bug by opening a new issue; it's that easy!
Great Bug Reports tend to have:
- A quick summary and/or background
- Steps to reproduce
- Be specific!
- Share the snapshot, if possible.
- What actually happens
- What you expected would happen
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
People love thorough bug reports. I'm not even kidding.
By contributing, you agree that your contributions will be licensed under its MIT License.