Pre-release news

[nibdo]

Hello,

I would like to share few (good) news for everyone.

1. Performance

Speed: I have made some optimizations and improvement for speed, so layout calculations are much faster. The most noticeable difference will be in month view.
Calculations on server: I will extract some calculation logic for those who would like to use server to precalculate positions for app.
Worker: I tested web worker to free rendering during calculations. It works great, but I still need to find way how to build worker from those functions dynamically. Basically it needs to merge all functions and imports to one file.

Either of this should improve performance if you need to load many events.
As changes are quite big and there are still some bugs, I will release it later after some internal testing.

2. Interface

I was thinking about improving interface by integrating Chakra Ui to replace custom components. What do you think about it?
https://chakra-ui.com/docs/getting-started

[lwhiteley]

Hi @nibdo . Thanks for this very nice library.

I spent some time testing and looking through the docs and have a few comments regarding this post and some may not be. These are just my opinions, so you can take what you will from it. This may be more fitting for the actual Discussions section though

Dependencies

I think generally it is better to reduce the need to use other react libraries in this library. The more you use, the more this library itself becomes opinionated about which libraries to use in a wider application. Usage of react-i18next and chakra-ui are very specific libraries and if a developer wants to use this library then they will have to accept all these extra libs as dependencies and their sub dependencies as well. For eg chakra-ui uses emotion but if an app uses styled-components then they would technically have to include both in their bundle.

Translation suggestions

Should maybe allow translations to be bootstrapped as a prop always. Only importing the default language by default.
so instead of specifying customLanguage as a flat list of translations, the dev is responsible for importing the specific supported languages. The library could specify.

import en from 'kalend/locales/en';
import de from 'kalend/locales/de';
import nl from './custom-nl.json';

// import translations from 'kalend/locales'; // if dev wants all locales

<Kalend 
 translations={{
   en,
   de,
   nl
 }}
  locale="en" // specify which locale to use
/>

Personally i think i18next may be overkill to use as well. It also means there will be some version locking involved.
in the library, one could generally use simple key and translation replacements if there is nothing special required from i18next.

ui suggestions

instead of chakra ui, maybe keep the ui components simple and allow an interface to replace components.
This way the dev would have flexibility to use whichever library they please.

<Kalend 
 components={{
   todayButton: (props) => <button />, // props passed in from library to give control to dev
   ...
 }}
/>

[nibdo]

Hi, @lwhiteley,

thank you, you have good points. And yes, i18next could be easily replaced here with some simple parser, that was actually my first thought before implementing localization.

About UI improvements, replacing whole header control panel is planned, I just felt, that standard components from some library could improve basic look, but you are right. It seemed as quicker solution using library, but there are only few components, so it could be improved over time.