Publishing package?

[ChetanBhasin]

I know that the project is still not fully finished, but how do you feel about publishing the package for people to start testing?

[illodev]

@ChetanBhasin Sorry for the wait! I plan to work on that this weekend and push some major changes.

[ChetanBhasin]

Oh that's amazing! Looking forward to trying it out!

[Luky1337]

Hi, may I ask how is it looking with publishing the package?

[illodev]

Hi @Luky1337 and @ChetanBhasin , I haven’t had the chance to publish the packages yet, as the weekend was quite busy. I'm currently integrating Changeset, which is new to me, and I’ve also set up Turborepo while packaging the TypeScript and ESLint configurations.

I'm almost done with the changes and will be pushing them soon! (Before this weekend for sure)

[illodev]

Hi, I've released a beta version. You can check out calendar/apps/demo/src/app/[locale]/calendar/page.tsx to see the simple usage of the component. I'm creating documentation to lay the groundwork for the project. I've made visual changes. I've also removed the drag&drop dependency, replacing it with my own drag&drop.

Dependencies you need to install Important to use version ^0.0.1-beta.0, example:

...
  "dependencies": {
    "@illostack/react-calendar": "^0.0.1-beta.0",
    "@illostack/react-calendar-day": "^0.0.1-beta.0",
    "@illostack/react-calendar-month": "^0.0.1-beta.0",
    "@illostack/react-calendar-range": "^0.0.1-beta.0",
    "@illostack/react-calendar-week": "^0.0.1-beta.0",
...

Core:
@illostack/react-calendar

Views (depends on which ones you want to use):

@illostack/react-calendar-day
@illostack/react-calendar-month
@illostack/react-calendar-range
@illostack/react-calendar-week

I also developed a standalone state manager to improve calendar performance and avoid relying on React states. You don't need to install it, but feel free to use it in another project if you need to :)

@illostack/react-store

Thanks for checking in. Sorry for the delay. If you have any questions, please write here and we'll get back to you as soon as possible.

[ChetanBhasin]

Hey! So I tried it out and I have some feedback:

The currently released versions on NPM have some issues since the packages rely on each other. Some packages are in 0.0.1-beta.2 and others are in 0.0.1 or 0.0.2 I'm not entirely sure what went wrong there.

Anyhow, I just copy pasted the code locally and tried to use them locally. There are still some issues though. Let's address them one at a time:

1. The calendar is still developed as an application and not as a library so integrating it into another application is not that easy. For example, the hooks library. I understand that you've built your own, but I think using something standard here makes a lot more sense. But that's not really a big deal.
2. A larger challenge is that unlike other libraries that provide you callback for when a time slot is selected or an event clicked on or selected, the event form is integrated directly in the application. So for an application that wants more information it cannot do that. Imagine an application where the user also cares about recurring events. The create form gets that information from the user and the backend returns the events that should be displayed on the current calendar. Or for example, if an application works with multiple calendar and requires collecting the calendar in which the event needs to be created in that form. Because the form is part of the calendar, the user is stuck in the information that create and update form can collect.

I'm still playing around with it and will probably have more feedback later. I wasn't sure the best way to give you feedback so I'm just leaving a comment here.

[ChetanBhasin]

Oh, another thing that I found out that the toasts are built into the calendar as well. That's probably not ideal for integrating it into another application that might have a different system for notifications or another toast implementation built in.

[illodev]

@ChetanBhasin I totally agree, the calendar started out as an integrated application. But I decoupled each thing, and today there are several things to decouple, as you say: forms, notifications, validations, etc. I think that all this, as you say, should not be my responsibility and let the developer integrate his logic and components there. This is something I'm going to do, no doubt, but I'm going to modularise it, that is, I'm going to give the possibility to integrate my ready-made form modules and let them integrate in some way. I've found that most people want things pre-made and I'd definitely like to give both options.

In short:

• Decouple dependencies/custom components (forms, notifications,etc)
• Add all the callbacks that would be needed for the decouple

For example, the hooks library. I understand that you've built your own, but I think using something standard here makes a lot more sense. But that's not really a big deal.

What exactly do you mean by that?

I still need to document everything, I'm sorry if I'm not going as fast as I can. But I'm between other projects, work, this... All feedback helps me to go faster and focus on the real issues in the package.

Thanks for taking your time, I'll reopen this and if you want you can comment me all you want here! Thank you very much!

[ChetanBhasin]

About the hooks library, sorry I meant the react store that you implemented.

I gave it a crack too today, but unfortunately writing frontend code is not my area of expertise.

Another thing that I noticed is that splitting the calendar between various components is also not really necessary. In fact, it adds more complexity to the whole process.

Another thing that I was thinking about (but haven't looked at yet) is if there are any caveats to keep in mind using it with regular React instead of using NextJS, but it might not be the most important thing for now.

[ChetanBhasin]

I'm sorry if I'm not going as fast as I can

Well, it's your project. You're doing a great service by open sourcing it. I don't think you have anything to apologise for. Your effort is appreciated! :)