Upgrades theme-ui to the latest version

[cmaycumber]

Upgrades theme-ui to the latest version.

Solves: #68

• Upgrade packages
• Solve all breaking changes
• Testing

[nandorojo]

Some breaking changes I've found:

• JSX pragma: https://theme-ui.com/guides/jsx-pragma

Will list more that I find outside of the changelog.

[nandorojo]

Here's a thought:

Could we detach fully from theme-ui? It's only used for 2 things:

1. TS types (for sx, SxProps, etc.)
2. Context (ThemeProvider, and hook for getting the theme)

For 1, could push a breaking change, that requires users to use ThemeProvider from theme-ui separately if they're using theme-ui's jsx pragma directly in web files.

For 2, we could just have a DripsyThemeContext. Since we already export the hook as useDripsyTheme, we can easily just return the theme prop there.

I also noticed that ThemeProvider is triggering re-renders, even though my theme is declared outside of render code. No idea why that is, might be a theme-ui bug.

This way, we'd only need theme-ui as a dependency for TS types.

I've been a bit disillusioned that theme-ui still hasn't added strict type support after years. By decoupling, we could add more features ourselves.

[cmaycumber]

Here's a thought:

Could we detach fully from theme-ui? It's only used for 2 things:

1. TS types (for sx, SxProps, etc.)
2. Context (ThemeProvider, and hook for getting the theme)

For 1, could push a breaking change, that requires users to use ThemeProvider from theme-ui separately if they're using theme-ui's jsx pragma directly in web files.

For 2, we could just have a DripsyThemeContext. Since we already export the hook as useDripsyTheme, we can easily just return the theme prop there.

I also noticed that ThemeProvider is triggering re-renders, even though my theme is declared outside of render code. No idea why that is, might be a theme-ui bug.

This way, we'd only need theme-ui as a dependency for TS types.

I've been a bit disillusioned that theme-ui still hasn't added strict type support after years. By decoupling, we could add more features ourselves.

I'm interested in this change as well. Should we just close this PR and try to open one that's more in line with this approach?

[nandorojo]

Yeah I think that makes sense

[nandorojo]

Once we do "detach" from theme UI, this would be my favorite feature to implement: system-ui/theme-ui#1090

I wonder if we could cherry pick some of the logic from that PR into Dripsy. One goal would be to keep it simpler. There would be no magic styles when creating the theme itself; only on the actual sx prop. I want to see auto completes for colors and such as I type them.

Also relevant to #72

[cmaycumber]

Once we do "detach" from theme UI, this would be my favorite feature to implement: system-ui/theme-ui#1090

I wonder if we could cherry pick some of the logic from that PR into Dripsy. One goal would be to keep it simpler. There would be no magic styles when creating the theme itself; only on the actual sx prop. I want to see auto completes for colors and such as I type them.

Also relevant to #72

Yeah, that would be awesome. Going to close this now.

[cmaycumber]

Here's a thought:

Could we detach fully from theme-ui? It's only used for 2 things:

1. TS types (for sx, SxProps, etc.)
2. Context (ThemeProvider, and hook for getting the theme)

For 1, could push a breaking change, that requires users to use ThemeProvider from theme-ui separately if they're using theme-ui's jsx pragma directly in web files.

For 2, we could just have a DripsyThemeContext. Since we already export the hook as useDripsyTheme, we can easily just return the theme prop there.

I also noticed that ThemeProvider is triggering re-renders, even though my theme is declared outside of render code. No idea why that is, might be a theme-ui bug.

This way, we'd only need theme-ui as a dependency for TS types.

I've been a bit disillusioned that theme-ui still hasn't added strict type support after years. By decoupling, we could add more features ourselves.

If I start on this, do you have any direction you want to take? Should we try to mock the latest API used by theme-ui or just start replacing each piece of the current API we're using with theme-ui with internal code?