Hi @leroydev , thank you very much for deep dive into code and propose optimization!

However, adapter is designed to be a global config. Just like you need to config global providers for redux, some UI libs, etc. So using nice form consists of two parts, one for config and the other is real usage.

Hi @supnate, thanks for taking the time to review quickly!
What do you think about adding a comment above the example code that adds the adapters, that mentions this should only be done globally but is done within the example to make them self-contained?
Then you have the best of both worlds, users can more quickly setup an example locally to play around with it and it is clear to them that the adapters is supposed to be global configuration.

If not, I do feel that including the definition of the custom datepicker in each example does add value.
Otherwise the user will be searching for a bit and would have to run into the one example that does have that code in it.

And the lazy loading should make the docs faster to load so might also be an improvement you want to consider.

Let me know which parts you want in what form and I'll make adjustments 🙂

Thanks @leroydev .

1. The get started section in readme should help users to know how to configure nice form. Examples mainly shows different scenarios of usage.
2. For widget definition, we think it's usually configured globally for common widgets to avoid duplicated code. But I agree adding a doc link would be helpful.
3. Lazy load for examples code is good change 👍

Closed in favor of #6