Looks cool but im always discouraged by any UI kit that isn't optimized for mobile devices in their demo elements on the front page. Might wanna check the experience on iOS safari ;)
I've checked out the <Modal /> component [1]. What's the reason to go through so many hoops instead of just using the HTML native <dialog> element [2]?
I'm waiting for the UI library that also animates everything out that it animates in. I know why people don't do it (it's annoying to do in React), but this gross lack of attention to detail in even the biggest-name software really bothers me. The UX sucks. If you're not going to animate it out, just skip animating it in to at least be consistent!
This isn't meant to be a dig at this specific library* (it's certainly no worse than others and you probably did a great job!), but rather the general state of React UI development.
*however this library already uses Framer Motion, which makes such things much easier
Curious why you went with RadixUI over HeadlessUI? Not that you shouldn't, just wondering what your decision process was.
I also noticed in `_app.tsx` that you wrapped <Component /> in a <main> element. Wouldn't that wrap the entire app within main tags? I think that kind of throws off the normal flow of accessible landmarks.
I really like the template so far. Might add a few aspects of it to my own. Thanks for sharing
AFAIK Radix has better a11y support than HeadlessUI, which is why I went with that!
As for the second point – I'm actually not quite sure if there are any downsides/tradeoffs to that. What do you mean by accessible landmarks in this case? a11y?
Since this is for your and other peoples' new projects, I'd rather recommend you use the app/ in Next 13 rather than pages. I'm told Vercel themselves are doing most new things in app/
I already don't wanna use it when I see api like 'useLocalStorage', when does this end the spreading of this garbage hook thing? What does local storage have anything to do with render cycle?
It's pretty simple, conceptually. It's like useState but saves state in localStorage. It has exactly the same stuff to do with the render cycle as useState.
no? You wanna duplicate local storage as a state in memory, and doing that you create some unnecessary hook that does the read write assuming re-renders. So now your codebase will have 2 different ways of doing localStorage, the normal, predictable way, when re-rendering isn't needed and the hook way.
I love Vercels design, I remember reading on their discussion page that they were working on open-sourcing their components and design system, but that was about two years ago?
This seems kinda weird. Random UI components, ORM, and string formatting utilities(???) all part of the same “thing”? I don’t get what this is, seems like a mishmash.
Hey! OP here – this is meant to be a powerful hello-world template that you can clone when you start a new Next.js project, something that I built for myself because I start way too many side projects haha
If you want to learn, my advice would be to focus on learning one thing at a time. Pick up react. Just react. NextJS (and other libraries included here) solve specific problems in specific ways. It's hard to know if they solve them in the way that works for you if you don't understand the problem they are solving, or what other approaches might look like.
Once you're comfortable with how react works, then start layering in additional libraries and tools, and get a feel for how they work. You may also find they introduce new pain points that don't work for your particular project. When you're trying to learn everything all at once, it's hard to figure out where a pain point is even coming from.
Totally disagree. Trying to fully understand a stack this tall from the get-go would be a huge barrier
One of the best things about Next is that it configures everything for you and lets you just start writing some React code and seeing results. I would recommend the GP start with Next, and dig deeper as they go along
Agreed. React by itself is mostly unusable for building anything – although that is slowly changing but alas: NextJS gives you a more solid starting point to build stuff around React.
Precedent seems a little half-hearted at this point.
I highly recommend learning Next.js as a way to learn React – it is built on top of React and focuses on some of the most important hooks (useState, useEffect) while also giving you functions for server-side rendering that help make sure your app is performant from the get-go.
That's actually how I learned React myself :)
Disclaimer: I work at Vercel (we maintain Next.js)
The under-the-hood stuff also has never bitten me and that's exactly what I want an isolated, composable component to do for me anyway. Performance is excellent.
Hey! OP here – this is not meant to be a design / component system, though I plan to add more components to it in the future if it makes sense. Rather, it's meant to be a powerful hello-world template that you can clone when you start a new Next.js project.
Highly recommend Radix if you want more components!
It's a good start, but definitely keep it up.
[1] — https://github.com/steven-tey/precedent/blob/main/lib/hooks/... (you don't need the ref if you are ignoring exhaustive-deps, not sure why you stringify threshold)
[2] - https://github.com/steven-tey/precedent/blob/main/lib/hooks/... (you maybe want to check if a key exists and warn before you set it)
[3] - https://github.com/steven-tey/precedent/blob/main/lib/hooks/... (you probably want debounce/throttle options here)