nextjs-boilerplate
nextjs-boilerplate copied to clipboard
A bunch of hooks
What kind of change does this PR introduce? (check at least one)
- [ ] Bugfix (non-breaking change which fixes an issue)
- [x] Feature (non-breaking change which adds functionality)
- [ ] Code style update
- [ ] Refactor (refactoring or adding test which isn't a fix or add a feature)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Build-related changes
- [ ] Other, please describe:
Does this PR introduce a breaking change? (check one)
- [ ] Yes
- [x] No
Did you test your solution?
- [ ] I lightly tested it in one browser
- [x] I deeply tested it in several browsers
- [ ] I wrote tests around it (unit tests, integration tests, E2E tests)
Problem Description
We often need a set of hooks on every project and end up copy/pasting them from previous projects.
Solution Description
I'm adding the most common ones I've been copying/pasting over the last year. I like to have these included on the boilerplate itself, instead of in "@jam3/react-hooks" because it allows us to make modifications based on the project requirements, which often becomes very complicated if the hooks are defined in a separate package.
Side Effects, Risks, Impact
- [x] N/A
Aditional comments:
@edgardz instead of adding these here we should add them instead in the separate repo here https://github.com/Jam3/react-hooks it's already used with generator
Actually looking at these. I'd say that most of them should sit within the boilerplate because they use the new services that have been added. If they sit in the react-hooks repo then they can't make use of the services.
we also have some of them already in the hooks repo such as intersection observer, orientation etc I think we still need to find a way to keep this modular in the hooks repo rather than bloat generator as these are not all necessarily needed on every project
@jmckinnell @namniak I think we can talk more in the open source meeting tomorrow
I have been working on updating the hooks repo to a 2.0 with Typescript, way more hooks and multiple improvements (I'm also using the services heavily)
I already talked with @edgardz about it and we agree to keep it in the repo so that the hooks are exposed, since sometimes we have to change them slightly but at the same time is true that is a bit of bloat and we don't need all of them usually.
Regardless I would like to update the hooks repo since is the perfect case of a modular library and can be used outside the generator.
I'm a bit busy now with Complex but I'll try my best to have it next week
Let's have a meeting to talk about it, but in the meanwhile, I propose to merge them, and then decide later what to do.