Can we have more details about the incoming breaking changes?

[danielo515]

Hello.
First of all, I want to thank you for this awesome library. It really helped me delivering a project within one day, where before using your library I was mentally blocked due to my lack of knowledge about tailwind, I was just overwhelmed.
I really enjoyed using it, it allowed me focusing on learning solid and my specific domain problem.
I loved the API from the very beginning. It just feels familiar, and has a lot of valuable things for someone like me (which easily overlooks things). Some of the things I liked the most are:

• Getting my editor telling me which properties are availabe and their possible values without me having to configure it at all
• Having my back covered by typescript warning me when I try to use non existing values. I can not highlight enough how many times my css was not working because a typo in a class
• I can code my entire component within the same file. Not having to jump between css and tsx file is a huge time saver for me

For that reasons I am a bit concerned about the incoming breaking changes. I find it a bit to short and it let me wondering what exactly will be removed. Will all the components that are not active components (box, center, grid, simple grid etc) be removed? Will I loose the ability to customize the variants, themes and colors using @radix-ui/colors? All the css and style customization options will be removed, along with their autocompletion features?
Also I would love to read more about the reasoning behind the decision if that information is publicly available.
If all the above is true, which options will have those who like the current API? other than pinning the package version, will the old docs be still available? I guess no patches either will be retro added, but I'm fine at the current state.
Thanks again

[fabien-ml]

[Edit 2022-08-03]: I've decided to keep the library "as is" with css-in-js, style props, layout components etc.

(outdated) original answer :

Hi,
First of all, I'm sorry that the upcoming changes in the library causes you problem and apologize for that.

---

Will all the components that are not active components (box, center, grid, simple grid etc) be removed?

Yes, because it can be done in css or with utility library like TailwindCSS, for example :

// Hope UI v0.x `VStack` 
<VStack space="$4" />

// TailwindCSS equivalent
<div class="flex flex-col space-x-4" />

Its not that "easy to read" but i'm ok with that tradeoff.

---

Will I loose the ability to customize the variants, themes and colors using @radix-ui/colors?

No, but it will be done in CSS, the only JavaScript part that will be kept is the ability to globally set default props for a component.

Here is an example of using tailwind and overriding Hope UI styles :

/* index.css */

/* Add tailwind base layer */
@import "tailwindcss/base";

/* Add Hope UI base styles */
@import "node_modules/@hope-ui/css/base.css"; 

/* Add tailwind components layer */
@import "tailwindcss/components";

/* Add Hope UI components styles, only what you need */
@import "node_modules/@hope-ui/css/alert.css";  
@import "node_modules/@hope-ui/css/button.css";
@import "node_modules/@hope-ui/css/menu.css";

/* Add tailwind utilities layer */
@import "tailwindcss/utilities";

/* Override Hope UI css variables */
:root {
  --hope-colors-primary-9: 10 255 128; /* defined as rgb color channel, so it can be used with tailwindcss opacity modifier */
  --hope-alert-border-radius: 8px;
}

/* Override Hope UI classes */
.hope-button--outline.hope-button--accent {
  background-color: salmon;
}

---

Also I would love to read more about the reasoning behind the decision if that information is publicly available.

• I don't like to use the library in its current state.
• Hope UI is not easily customizable
• Style props clutter components API with hundreds of props, making it hard to find things with IntelliSense
• Stitches has a (small) runtime cost since its a runtime CSS-in-JS library
• Stitches was not built to do dynamic style props, the solution i've made is a hack around Stitches css prop.
• Style props are not easily overridable, because of the previous point.
• Each style props combination set on a component make a unique class, creating an infinite amount of classes in the application

For all that reasons :

• Hope UI 1.0 is moving away from CSS-in-JS solution and will ship plain old CSS file with BEM naming convention.
• Since it will be just "normal" CSS files, you can pair it with your styling solution of choice for other parts of your application.

---

If all the above is true, which options will have those who like the current API?

The Chakra UI team mentioned that they will be working on a SolidJS version of they library, maybe worth waiting for it since Hope UI v0.x was inspired by this library.

---

other than pinning the package version

Since v1.0 is a complete rewrite it will not be in the @hope-ui/solid package, i will take advantage of it to publish a new @hope-ui/core package instead.

The @hope-ui/solid package will stay as is on npm and will be deprecated.

---

will the old docs be still available?

Yes it will be hosted at v0.hope-ui.com and I will put a link to it in the new doc.

[danielo515]

First of all, I'm sorry that the upcoming changes in the library causes you problem and apologize for that.

O man no, I am already grateful for what it is already. It allowed me to accomplish much more than I could without it, so even if it stays in its current state, is perfect for me already.

Here is an example of using tailwind and overriding Hope UI styles :

Yeah, definitively not as ergonomic and not of my taste, I will for sure stick to the 0.X version.

• Style props clutter components API with hundreds of props, making it hard to find things with IntelliSense

My experience was exactly the contrary, but I guess it really depends on each person.

Yes it will be hosted at v0.hope-ui.com and I will put a link to it in the new doc.

That gives me peace of mind.

Thank you very much for your detailed answer!

[fabien-ml]

Hi, after a long reflexion i've decided to keep the library "as is" with css-in-js, style props, layout components etc.

I'm working on a new style engine and theming API that will be even better, more details soon.

[appurist]

I love what you've done with Hope UI, so this is of course good news to me. And I gave a bit of grief from hesitation (in Twitter? I forget where). However, I had also come to the conclusion that I would support any future direction you took, whether backwards-compatible or not, as there is no better choice for SolidJS apps, and Hope UI is wonderful. And nobody knows this package better than you, so I trust that you will review options and pick the best one for the project. And here it is. ;) I love what you've done with theming so far so any improvements would only make this a slam-dunk success. Thank you for all you do.

[fabien-ml]

Thanks @appurist I appreciate the support 🙏. after further exploration I've reach the conclusion that css-in-js and the style props are the best compromise between DX customization and performance.

I will publish an RFC in a couple of days with an alpha version of the new package for people to test.

For me the new theming and style props API is👌

[fabien-ml]

First pre-release is here.

There is not a lot of components, its mostly for testing the new styling/theming api.

Depending on my time dedicated to open source, I expect reaching feature parity with v0.x at the end of the year.

If you want to give it a try, go to http://next.hope-ui.com

[apollo79]

Is this timeline (feature parity at the end of the year) still up to date?

[fabien-ml]

Sadly I don't think so, I've less time dedicated to open source (about 8-10h per week) and don't want to rush it and have poor quality.
I don't have a final release date in mind currently.