v4.0

[kennethnym]

This is an issue tracking this library's upgrade to v4.0.

New features:

• Support for Bulma 0.9.1
  • Spacing helpers
  • Light/Dark color helpers
  • Remove <List /> component
  • is-clickable helper
  • is-max-desktop and is-max-widescreen for Container
• Standalone display prop without viewport modifiers. (5f1b1eb)
• Support is-size-7 (2162f3f)
• Support font family modifiers (d82cee8)
• Support for is-sr-only modifier (e9fc3d2)
• Tree shaking
• Update Documentation for installation process (Now there will be only one no more advanced configuration need it)
• TypeScript support
• Add missing table-container component (fix: add missing Table.Container element #274)
• Add missing hoverable prop for Table component (fix: add missing table hoverable prop #273)
• Add missing rounded prop for Form.Select component (aed5774)
• Add various state props for Form.Select (d2afa6d)
• BREAKING name prop of Form.Radio is no longer required. (b365663)
• BREAKING Simplify responsive props (Simplify Responsive prop #279)
• BREAKING remove Breadcrumb item prop and replace it with Breadcrumb.Item
• Ability to show the first and last page in Pagination (Add pagination first last pages #283)
• BREAKING Remove loading Button prop in favor of a unified state prop that already exists. Button can have multiple state at once - the state prop will be removed because it can only take one state at a time. (0da8632) Reverting this, does not make sense to have focus, hover and/or hover at the same time
• Add focus, hover and loading (UPDATE loading state is applied to Control instead of Input, removing) state props for Form.Input. (aff9690)
• Add rounded prop for Form.Input (corresponds to is-rounded) (af1c3a2).
• Add centered prop for InputFile
• BREAKING Remove Form.Textarea default rows of 4. (2153d5b)
• Add has-fixed-size support for Form.Textarea (2153d5b)
• Add various state props (loading, focused, etc.) for Form.Textarea (2153d5b) Reverting this, does not make sense to have focus, hover and/or hover at the same time
• BREAKING Form.InputFile is now a controlled component
• BREAKING Heading will now pick the appropriate header element based on the supplied size. For example, size={4} tells Heading to render h4 under the hood. Default size will now be 3 Won't do, the user will select the appropiate element with renderAs
• Allow override of renderAs for various components for consistency's sake. Except Table because with any other component will not work

Housekeeping:

• BREAKING Move bulma to peerDependency ([VOTE] Change Bulma dependency to peerDependenc. and remove the import of the styles from this library #258)
• BREAKING Move Remove sass import from codebase
• Remove yarn.lock
• (Optional) Rewrite class components with hooks.
• (Optional) Review how we exports the components and see if there are no a better way
• Remove default HTML attributes/React props from propTypes object (for example style, disabled) unless it is accessed by the component.

cc @couds

edit: marked breaking changes.

[kennethnym]

@couds Bulma 0.9.0 contains some breaking changes, so we have to do a v4 release on this. Maybe push #258 to v5?

[kennethnym]

For TypeScript support, I am currently stuck on supporting advanced imports. It seems like to only way to support advanced imports is to manually re-export all component types under their corresponding advanced import path.

[kennethnym]

Other than that, type definintions should be largely complete.

[couds]

@MrCreeper1008 in which branch are the typescript definitions? I have an idea to fix the import that want to check

[kennethnym]

It's on ts-defs

[kennethnym]

I think we should come up with a better way of importing components, because imo current way of doing it is a bit cluncky. Maybe we should consider supporting tree-shaking?

[kennethnym]

@couds we should also probably rewrite all class components with react hooks, since react recommends hooks over classes.

[couds]

Hi @MrCreeper1008 I think we can do it but that is not a breaking change so we can do it later (v4.1 for example) so let out it as optional for the 4.0.

[verheyenkoen]

@MrCreeper1008 @couds Maybe create a dedicated branch for that? Or can we just send pull requests on a per component basis?

[kennethnym]

Typedefs for compoentns are finished. We're just considering changing how components are imported, so we're holding this off until that is settled

[alexpchin]

Hi, loving the work! Just wondering whether you have an ETA for this update? It seems almost there?

[kennethnym]

yea it is almost there. waiting @couds to rewrite imports.

[couds]

Hi @MrCreeper1008 Thanks a lot for all the work you are doing. This couple a week had been crazy for me. (Changing job and finishing a lot of stuff), I think I will have finally time after Sep 15. I will try my best to do it the weekend of that week. T_T

[kennethnym]

if you want i can finish the rest so you can focus on your stuff.

[timorthi]

Hi, love the library and 4.0 looks to be a great update. Is there anything we can do to help push the project closer to a 4.0 release? 😄

[kennethnym]

The only big thing left to do is closing #276, so it would be great if you could help with that.

[kennethnym]

Also would be great if you could help improve the documentation.

[kennethnym]

I should be able to finish v4 this week, but it will be released definitely by next week. Sorry for the delays. There are too much stuff going on right now.

Update: all changes are implemented! still deciding whether to rewrite class components. @couds

[davepwsmith]

I am using #next in a hobby application - have noticed that a few of the type exports are missing from index.d.ts, namely:

export {Menu} from './components/menu';
export {Tag} from './components/tab';
export {Tile} from './components/tile';

Not sure if this is overlooked, or intentional, but thought better to point it out :)

D

[kennethnym]

Turns out the memory issue is an issue on ts-jest: kulshekhar/ts-jest#1967. Basically, compiled modules are cached redundantly.

[fgs-dbudwin]

Reading that issue, it looks like the underlying issue may be with Jest itself--the issue was crossposted here: jestjs/jest#10550

Not much activity on it. I take it that you're not using ts-jest which is why you're not seeing the same issues I am.

[kennethnym]

My guess is that the issue only happens in large projects with many test cases. A solution is for us to ship a commonjs version of our code that you can import in tests (like react-bulma-components/lib/index.cjs) but I am reluctant to do so because I reckon very few people will use it and it's not worth the extra installation time. @couds thoughts?

[fgs-dbudwin]

Can you explain to me what changed between v3 and v4 to expose this issue?

[kennethnym]

in v3 import statements are transpiled but in v4 they aren't anymore to enable tree shaking.

[kennethnym]

Marked breaking changes.

[kennethnym]

Some missing features are added when I am writing the new documentation. Decided to also perform some housekeeping tasks in v4 to tidy up the code base.

[couds]

Hi @ALL I took a while but finally we have a release candidate for V4. You can try it installing the next tag npm i react-bulma-components@next

If not big issues are found I will release it next week

Thanks for the patience!

[davepwsmith]

@couds I have been using the v4 branches for a while, and this seems to break quite a lot that was previously working in terms of types in particular, but also functionally - is there an easy way to see what has changed, or view the docs so that I can work out how to update these?

One thing in particular that I think will need updating is the types on renderAs - I am using Gatsby, and it won't let me use a gatsbyLink as renderAs, which is pretty crucial e.g. for navigation. (#314 (comment))

I'm going to take a look and see if there is anything I can do about it, but thought I would let you know early!

[kennethnym]

can you open a new issue for the problem you have with gatsby and renderAs? as for the changelog i think @couds is documenting all the changes in CHANGELOG.md on the next branch.

[davepwsmith]

Me again (perhaps it's only me that's using this unstable branch!) - I have found that the changes in RC.3 have made gatsby fail to build:

 ERROR #98124  WEBPACK

Generating JavaScript bundles failed

undefined

If you're trying to use a package make sure that 'undefined' is installed. If you're trying to use a local file make sure that the path is correct.

File: src/pages/index.tsx:1:94

Everything works fine with RC.2, but 3, 4 and 5 throw this.

[couds]

Hi @davepwsmith

I made a mistake building RC.3, check the latest one (Should be RC.5) it should work correctly

[davepwsmith]

Afraid not @couds - neither .3, .4 or .5 work, all with the same error.

[couds]

Weird. I will check this afternoon what its broken on the build and deploy a RC.6.

If possible can you share a simple repo to reproduce the issue?

Thanks

[davepwsmith]

https://github.com/davepwsmith/rbc-error-repro

[couds]

@davepwsmith Fixed on RC.7 Thanks for reporting.

[davepwsmith]

Just to confirm that this is all good at my end with a more complicated example than the one I gave you! Thanks.

[bino98]

Hi.

Some typescript type definition maybe different.
The problematic part is MenuListItemProps used in <Menu.List.Item>.
https://github.com/couds/react-bulma-components/blob/v4.0.0-RC.7/src/components/menu/index.d.ts#L10

An type mismatch error occurs even if I use it according to the usage of bulma documents.

<Menu>
  <Menu.List>
      <Menu.List.Item>
        /* ↓ Type mismatch.. 'string[] | ReactElement<any, string | JSXElementConstructor<any>>[]' */
        hogehoge
      </Menu.List.Item>
  </Menu.List>
</Menu>

My team is using RC.7.

[couds]

Hi @bino98 I will take s look. Thanks!

[davepwsmith]

For what it's worth, unless you are specifically trying to restrict what people put inside these elements, I think you will pretty much always want ReactNode? It is the type that the react typings use for children (e.g. in PropsWithChildren<>).

It is a very broad type though, so if you did want to restrict further than that I would understand!

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/2034c45/types/react/index.d.ts#L194

[bino98]

Thank you comments.

I forgot to write past comment, even if use a ReactNode in <Menu.List.Item>, this problem occurs.

for examples..

<Menu>
  <Menu.List>
      <Menu.List.Item>
        <HogeLabel>hogehoge</HogeLabel>
      </Menu.List.Item>
  </Menu.List>
</Menu>

sorry if I'm wrong

[davepwsmith]

Hi @bino98 - sorry my comment was directed at @couds. You are correct that the types aren't right.

@couds I can PR for this - but I also noticed that the title attribute is already typed as ReactNode... this means that you can put just about anything as the title here, extending to basically a whole other website! Should this not just be "string"?

I am struggling to even get the "next" branch set up at the moment though, npm i is complaining about package hashes and babel won't run...

[couds]

Hi @davepwsmith

I will take a look about the issue with the env.

About the title, I prefer to keep it as a ReactNode, there are scenarios where we could want a more complex title (and anchor or anything else)

[couds]

@davepwsmith I pushed the fix to the Item definition. Thanks.

I was not able to reproduce the issue installing the package.

btw I recommend to use npm ci instead of npm i when installing the dependencies (it will only use the lock file and its faster

[bino98]

congrats for v4 release! 🎉

[kennethnym]

Thank you 😄