Avataw
July 8, 2022, 10:48pm
1
Recently I started a new project with Mantine a lovely UI-Library that I definitely prefer over MUI so far.
As you can see in their getting-started they do have buttons for getting started with Next, Gatsby and Remix among others.
Wouldn’t it be nice to have a template for redwood too?
That might improve visibility and so on ~
I am not sure what exactly this would entail therefore let’s discuss it here!
Wow, that does look nicer than MUI !! Thanks for the pointer !
Hey Avataw
I missed this post earlier… there is support coming for rw setup ui mantine
:
redwoodjs:main
← nickpdemarco:demarco/setup_mantine
opened 01:16AM - 24 Mar 22 UTC
## Reviewer's Guide
### Key files
- [`packages/cli/src/lib/merge/index.js` G… eneric AST merging algorithm](https://github.com/redwoodjs/redwood/pull/4900/files#diff-2f1591f61681f994c50fc7095ad06f3cc0ce46b0f4ffed10a5e3d9365f47ddb6R143-R152). Or, [read the docs](https://github.com/redwoodjs/redwood/blob/36f7987a8ff6fe6fac25a2a502b47176f40b9bd2/packages/cli/src/lib/merge/README.md), or [read the tests](https://github.com/redwoodjs/redwood/pull/4900/files#diff-6e142e517c398f771575bc386c169d7de6ba4b9ff0889f0f20d9f5818e8ddc47).
- [`packages/cli/src/lib/merge/strategy.js` Named higher-order merge strategies like `concatUnique`](https://github.com/redwoodjs/redwood/pull/4900/files#diff-6fae20f152ce749752d9b5e37d11f523323b0da5b589e3349493f6ee56086b45).
- [`packages/cli/src/lib/extendFile.js` New utility for modifying `App.js|tsx` etc](https://github.com/redwoodjs/redwood/pull/4900/files#diff-c7438aaecc86b7f0cecdb694f7aafa2a66e4d4dd1505e7bd832f32f86c5652fc).
### Straightforward changes
[`packages/cli/src/commands/setup/ui/libraries/mantine.js` Essentially a copy of chakra's approach](https://github.com/redwoodjs/redwood/pull/4900/files#diff-03ac7b67ee7eaa288c55a442ed6d8b906209597a609c56aea35add2984720c5c).
[`packages/cli/src/commands/setup/ui/libraries/chakra-ui.js` Tweaks to use new internal apis](https://github.com/redwoodjs/redwood/pull/4900/files#diff-58afa0aa52db25ab2d44bffb051aa295293d3364eb2a29520b11391176a84bac).
[`packages/cli/src/lib/configureStorybook.js` Now, just calls to `fs` and `merge`](https://github.com/redwoodjs/redwood/pull/4900/files#diff-440f8b590b16abb1872c52cae351f5a84b00cc8c22260626c09a7cd9cc4fe270).
## Description
### `cli/lib/merge`
This PR introduces a new `merge` sublibrary of `cli/lib`, designed to facilitate the merging of Javascript files. See [the README](https://github.com/redwoodjs/redwood/blob/36f7987a8ff6fe6fac25a2a502b47176f40b9bd2/packages/cli/src/lib/merge/README.md) for more complete documentation.
The merge implementation requires `@babel/generator` and `@types/babel__generator`, and both have been added to the framework-level `package.json`.
**Please note:** I consider this code to be `0.1` quality - I've really only provided tests to prove it works for mostly-reasonable, small javascript files. Much more testing is required before using it in contexts outside of Storybook configuration merges. **So, think of it as a foundation, rather than a perfectly complete, generic Javascript AST merger.**
### `rw setup *`
This merge algorithm is used in service of `rw setup i18n`, `rw setup ui chakra-ui`, and a newly-added `rw setup ui mantine`, each of which need to extend our storybook configuration file, which lives at `web/config` in Redwood Projects.
To accomodate this, we've slightly changed how we handle storybook configurations. First, we have a "base" configuration, which provides some useful examples and comments, but is a no-op from the perspective of Storybook. In the framework, the file lives at [`cli/src/lib/templates`](https://github.com/redwoodjs/redwood/blob/36f7987a8ff6fe6fac25a2a502b47176f40b9bd2/packages/cli/src/lib/templates/storybook.preview.js.template). If a user never invokes a Redwood command that requires a storybook configuration, they'll never see this file. However, if they do, said file will be used as the "base" into which command-specific extensions (e.g. those needed by i18n) will be merged.
This notion of "base" and "extension" occurs often in the merge code, and imply a handful of design decisions. Code in the base is considered sacred (since it may be user-generated) and is never deleted, overwritten, or otherwise manipulated in a lossy manner. As an example, leading comments on [semantically-equivalent](https://github.com/redwoodjs/redwood/blob/36f7987a8ff6fe6fac25a2a502b47176f40b9bd2/packages/cli/src/lib/merge/README.md#semantic-identity) nodes will prefer the base version. Assuming we're using a [`concatUnique`](https://github.com/redwoodjs/redwood/blob/36f7987a8ff6fe6fac25a2a502b47176f40b9bd2/packages/cli/src/lib/merge/README.md#concatunique) merge strategy for `ArrayExpression`, the following demonstrates a simple merge.
```js
/* base.js */
// my favorite variable
const x = [1]
```
```js
/* ext.js */
// a tolerable variable
const x = [2]
```
```js
/* merged.js */
// my favorite variable
const x = [1, 2]
```
### `extendJSXFile`
See [`extendFile`](https://github.com/redwoodjs/redwood/blob/36f7987a8ff6fe6fac25a2a502b47176f40b9bd2/packages/cli/src/lib/extendFile.js).
One of the earlier problems addressed by this ever-expansive PR was the manipulation of `App.{js|tsx}` during various `rw setup` commands. I still believe the implementation provided in this PR is an improvement over mainline, but I am beginning to wonder if `extendFile.js` could also be improved by some Babel-ification. In the interest of preventing yet-further scope creep on this PR, I leave that as a task for another time.
## TODO
I believe the code in this PR is now ready for proper review. It has grown considerably in scope from its original mission (to simply add Mantine as another UI provider), and as such it may be appropriate to split the merge code into another PR. If any of the reviewers here deem that appropraite, I can make the change this weekend.
Furthermore, I need to enrich the documentation in the source tree, as well as on the public-facing websites. I figure that shouldn't block a review, so I'm taking this PR out of draft.
- [x] Richer merge documentation with details on merge strategies, and deeper explanation of the overall approach.
- [ ] Short recorded screencast with overview of PR
- [ ] "Design Library Configuration" doc, with link added to `<lib>.config.js`
- [x] CLI Commands Doc
2 Likes
nomadme
September 30, 2023, 4:06am
4
How to make mantine work in the test? All my test is broken after adding mantine ui.
Error message: "@mantine/core: MantineProvider was not found in component tree, make sure you have it in your app"
From the mantine documenation, it seems that the render function needs to include the provider which requires creating a custom render function that should extend the main render.
Since the RW has its own render function, is there a way to tap in to the RW render function?
1 Like
In the App file verify that you have MantineProvider, if the tests still fail, wrap your components, for example:
it('Your test', () => {
render(
<MantineProvider>
<YourComponent />
</MantineProvider>
);
// Your test assertions go here
});
I hope this helped you.
Thanks for the reply.
Yes, I have the MantineProvider in the App that wraps properly.
I could wrap every component test like you suggested, but, is there a way that we can extend the RW render method and can use the customized render method for the ongoing tests?
maybe you are looking for this
beforeEach(() => {
})