Material-ui-pickers: [chore] Investigate size of published code to npm

[NawarA]

Is your feature request related to a problem? Please describe.
You're forcing devs to use 3rd party libraries:

• MUI Pickers = 1.49 MB
• date-fns = 33.6 kB + 10.5 MB = ~11 MB
• moment.js = 28.7 kB + 2.79 MB = ~3 MB
• luxon = 32.4 kB + 2.91 MB = ~3 MB
• dayjs = 31 kB + 439 kB = 0.5MB

Overall, you're forcing devs to download 2MB to 13MB. That's a huge download for a simple calendar "select a date" interface built atop the components in MUI.

Describe the solution you'd like
Drop the 3rd party integrations. The library would shrink to 1.5 MB or smaller (make it lean).

Size matters. Lean this puppy out. If you want to support internationalization, that's cool, but have a lean library, and then add an extension that's bigger for that.

Describe alternatives you've considered
Do devs want to download up to 13 MB for a calendar? Size matters. If someone offers the same functionality at 200 KB or a half meg, people may switch. No wants the size or bloat, they just want the GUI to return a Date object in JS. haha

Additional context
I appreciate you making this library. Just wish I didnt have to plug in 3rd party deps to get this to work :) rock on ❤️

[oliviertassinari]

@NawarA I'm confused by the problem you are trying to solve. It would greatly help if we could look at the gzipped sizes in production mode, as opposed to uncompressed and in development.

We offer the integration with third-party libraries to solve this very problem: reduce bundle size. In your case, if you have no prior date management need, and aim for the lowest possible bundle size, we would recommend the usage of dayjs. I hope it helps.

[dmtrKovalenko]

But in serious – it is mostly impossible to implement features parsing or localized format without dependency. Possible, but it will be as huge as with dependency (date-fns parse function gzip costs around 16kb), possibly buggy and will add additional overhead if you are using some library already

We need to investigate what we are publishing to npm, I think we can reduce download size of pickers code

[oliviertassinari]

@dmtrKovalenko We don't have many leverages for improving bundle size on the date picker side, some ideas:

• Remove Grid: seems a good one to tackle
• Remove CircularProgress: maybe a good feature to defer to userland
• keycode: I don't understand why we use a global keyboard listener (listening on the document), assuming we can listen the event on the component, and leverage the synthetic React event system, we can get rid of

export const keycode = {
  ArrowUp: 38,
  ArrowDown: 40,
  ArrowLeft: 37,
  ArrowRight: 39,
  Enter: 13,
  Home: 36,
  End: 35,
  PageUp: 33,
  PageDown: 34,
};

• Remove rifm: assuming it's not the default behavior, maybe it shouldn't be built-in
• I'm out of ideas

[dmtrKovalenko]

We need global for keyboard navigation, when using elements events it will not work when moving focus out. I tried to remove global events early v4, but some case was broken. Can try to find more details.

In v4 masked input is a default behavior
Agree for Grid and CircularProgress

[oliviertassinari]

it will not work when moving focus out

I would imagine that one listener on the textbox parent would be enough (containing the popup too). Alternatively, if we don't have a textbox container, we could use two listeners: one on the textbox and one on the popup.

[dmtrKovalenko]

I investigated the size and found that we are not publishing any bloating code to npm. So yeah, I think we can close this issue