[Task]: Hope UI 1.0 Release Checklist #187
Comments
|
@fabien-ml I'm going to start converting one of my personal projects to Hope UI rewrite and then use that to focus me on contributing back (e.g implementing some of the remaining components). Before I get started - which branch should I work from / any other things to keep in mind? Update |
|
@martinpengellyphillips you can start from the To create a component that support Hope-ui theming you need to learn about this https://next--hope-ui.netlify.app/docs/theming/style-config-api. I'm open to PR, but I want to keep control over the UI design. The visual style takes inspiration from Mantine and TailwindUI design. |
|
Also I'm currently on the |
|
👋, For anyone who's looked at this issue and haven't seen any progress for weeks, it's because I've decided to pull the heavy work done on the complex components into another (headless) library that will be used by Hope-UI under the hood. The repo is here: https://github.com/fabien-ml/kobalte |
Oh, this is cool! Thanks for the info! |
Love it! Had been hoping to use https://github.com/tw-in-js/twind with hope-ui, but saw that Stitches was hardcoded. Sounds like this change in direction should allow for something like twind. Curious - re headless patterns, are you leaning more towards the Radix approach, or React Aria approach? |
|
@marbemac it will be more like the DX of radix (component based), the API is very inspired from radix, but the a11y features are from react-aria. It's a mix of what I've learned from radix, ariakit and react-aria codebase. I've also made a tailwind plugin for easy styling but not sure if it apply to twind |
@apollo79 for Kobalte (the headless lib) i expect a
Then the "styled" version will be integrated in Hope-UI, but I haven't planned this part yet. |
Nice! Can't wait for Hope-UI v1! |
|
Do you plan to create datepicker component for kobalt anytime soon? |
|
Yes, there is a good date picker in |
|
Waiting for it, thanks) |
|
@fabien-ml I'm starting work on a foundational stack that I'll be using for new products moving forward, and am currently planning to use twind (with similar approach to your Kobalte tailwind plugin with the Given this, I am trying to decide the best course forward: a) Build my own component library on top of Kobalte (effectively, hope-ui, which seems kind of redundant). I just did a POC for (a) - creating a simple Button component with Kobalte + Twind - and effectively I ended up copying most of the Hope UI button code and just swapping out the stitches styling bits for twind driven styles. For B, I was wondering if perhaps hope-ui could somehow still allow for the classes/styles to be swapped out / driven by something other than stitches? Using the Button component as an example, all of the parts (root, icon, loader, content, etc) grab their classes from functions exposed on a context provider that wraps the button. What if that context provider was instead at the root (HopeProvider), similar to how the custom component theming is working right now. One would be expected to supply an object that supplies these class/style generator functions for all hope components. And then all of the stitches (or tailwind, whatever hope-ui ends up defaulting to) code is moved to a separate package that folks can use for easy mode. Just an idea as I dig into Hope UI and Kobalte - not sure what your plans are in general for styling for the Hope UI + Kobalte combo that you are probably working on now. Also haven't completely thought this through so there might be complexities or trade-offs I've missed 😅. PS - if this is better as a separate discussion or issue please feel free to move it! Back of the napkin example: /**
* Current code that's inside `button.tsx`. Generates class names via stitches,
* exposes those over a local button context provider.
*/
const { baseClasses } = useButtonStyleConfig("Button", styleConfigProps);
<ButtonContext.Provider value={{ baseClasses }}>
// Actual button
</ButtonContext.Provider>
/**
* Instead, a more generic call to a helper that under the hood grabs the object
* with the button part class names, from the root provider context.
*
* useStyleConfig(hopeComponent: "Button" | "Dividier" | "Heading" | "Modal" ...etc, styleConfigProps: RelevantPropsForHopeComponent)
*/
const { baseClasses } = useStyleConfig("Button", styleConfigProps);
/**
* Required `styles` object passed into root HopeProvider, for `useStyleConfig` to access.
*
* `defineStyles` wrapper mostly for typing support.
*/
const styles = defineStyles({
components: {
Button(props: ButtonStyleConfigProps): Record<ButtonPart, string> {
return {
root: '',
icon: '',
leftIcon: '',
rightIcon: '',
loaderWrapper: '',
loaderIcon: ''
}
}
// ... the rest of the hope components
},
});
// Pass the styles config into HopeProvider
const App = () => {
return (
<HopeProvider styles={styles}>
// ..
</HopeProvider>
)
}So refactoring the existing stitches based styling to this system might look something like this: // @hope-ui/stitches
export const styles = defineStyles({
components: {
Button(props: ButtonStyleConfigProps): Record<ButtonPart, string> {
// the same `useButtonStyleConfig` that is currently inside of `button/button.styles.ts`
return useButtonStyleConfig(props).baseClasses;
}
},
});Or tailwind based styles... // @hope-ui/tailwind
const styles = defineStyles({
components: {
Button(props: ButtonStyleConfigProps): Record<ButtonPart, string> {
return {
root: cx({
'bg-red': props.variant === 'danger',
// ... etc,
}),
icon: '',
// ... etc
}
}
},
});What's cool about this is that Hope UI is still building on top of Kobalte to provide a more opinionated set of ready to go components, while still allowing those that want to swap out the styling solution to do so. |
|
@marbemac sorry for the late response. I'm a bit sick and tired of CSS-in-JS, "being Chakra ui like", style props API and all the problems that come with (performance, SSR, TypeScript intellisense, the Stitches css-in-js lib used which is almost dead project, etc). My goal with Hope UI was to bring some well designed, accessible components, ready to use for people without any design skills, for creating PoC, side project etc. But currently I spend most of my time fighting with the problems above instead of building components. While building v0.x a year ago I've found the "Chakra ui like" API interesting, but there are so many drawback that i'm tired of. |
|
np, thank you for the response! |
|
After weeks of reflexion I've decided to move Hope UI away from CSS-in-JS and stop being a "Chakra UI like" library. Starting from
The I apologize for the problems that this announcement will cause to ongoing project using Hope UI, but as I've mentioned in comments above I'm tired of all CSS-in-JS related problem and don't want to invest more free time on this. In conclusion, starting from If you want to build something highly customizable I recommend moving to an headless library like Kobalte. |
|
Hi everyone and sorry for not communicating since January, here is some update about the future of Hope UI.
However since it's almost a new project from zero and to avoid confusion, i've decided to move it to another org and with a new name. So the official successor of Hope UI, can be found here: https://github.com/kobaltedev/pigment |
|
I would like to suggest changing the documentation and Readme to properly indicate that development on Hope UI stopped indefinitely and there is this new successor. I only found out about this because I read this Issue, but not everyone does or wants to do that, it's fairly long. There's also multiple warnings that a rewrite is in progress. The project looks very much alive, if you never see any of this. |
|
Any migration guide? |
1.0 Release Checklist
The following is an in progress list of remaining tasks before the release of 1.0 which is a complete rewrite of the library.
UI Components
In v1.0
In v1.x
The text was updated successfully, but these errors were encountered: