Calendar widget

[mastermajorman]

Create a new widget which allows users to:

1. View dates on a convenient and easily navigable calendar
2. Add notes to specific dates that are saved in local session
3. Allow integration of the sticky note widget into the calendar (essentially, let users set notes from within the sticky note that show up on the calendar)

Also, don't forget to add it to the store so people can add it.

[royanger]

I think we can add Todos to this as well, potentially.

[mastermajorman]

I think we can add Todos to this as well, potentially.

I like this idea. I'm utilizing someone else's component I found online and starting from there because it's pretty customizable. I'll probably implement some kind of "clear picture" mode for it as well where it just shows the current date with a Todo line or two below it kind of like this:

[mastermajorman]

@Melkeydev I'm utilizing the existing react-calendar library as a launch pad for this work. I only had to add calendar event storage and display below selected weekdays and then of course the condensed view which can be changed in the system settings.

It looks like a pretty reputable component. Let me know if this is okay. I've already cut the majority of the fat from the repo itself to make it more maintainable, but the dependencies and build process are still separate from ours. I can combine them and transition from babel->vite to further assimilate into Astrostation.

[Melkeydev]

@royanger Had a great point - can we just npm install the package instead of trying to re build it? we can build around it and make a widget with it

[mastermajorman]

@royanger Had a great point - can we just npm install the package instead of trying to re build it? we can build around it and make a widget with it

Those are fair points. I thought about using their npm scripts, but the dependencies are almost all sub-dependencies, so I wasn't sure how that would impact the final size of the build. Is Vite/Node smart enough to remove/ignore duplicate dependencies during build-time if versions match?

What about automated builds in the case anyone decides to change it in the future? Right now, I have to run their scripts directly. I guess that's something I could figure out with Vite to make things work better or at the very least add a note to future developers to manually build with changes present.

[royanger]

Is Vite/Node smart enough to remove/ignore duplicate dependencies during build-time if versions match?

Assuming the package is written correctly, full tree shaking occurs.

What about automated builds in the case anyone decides to change it in the future?

I'm not quite sure what you're asking, but if we install from npm there is no build step. The package can immediately be used in the project. I'm not sure what you're referring to with "in the case anyone decides to change it in the future?" but I suspect it is a moot issue if we're using the npm package.

[mastermajorman]

What about automated builds in the case anyone decides to change it in the future?

I'm not quite sure what you're asking, but if we install from npm there is no build step. The package can immediately be used in the project. I'm not sure what you're referring to with "in the case anyone decides to change it in the future?" but I suspect it is a moot issue if we're using the npm package.

I think there's a bit of miscommunication. I have not installed from NPM but rather utilized their source code directly with some modifications for the widget.

[royanger]

There is no miscommunication. I'm fully against that process unless we need to patch the package for some reason. We should not be taking over maintenance of a relatively complicated library via integrated it into our repo when we can simply npm install it. Yes, there are some issues with the npm ecosystem but with tree shaking it should be fine.

If we're going to have a calendar widget in the repo, my take would be to build it ourselves to spec. Keep it very lean with only exactly what we need and keep long term maintenance down.

[mastermajorman]

I'm fully against that process unless we need to patch the package for some reason.

This is why I am opting to go the route I have specified above. The package react-calendar does not have the full functionality that is desired for this widget. It is missing calendar events and a simplified weekday UI that I have specified is desired for the widget. Ergo, I am suggesting we take what they have now and build on it. That is to say unless you think what they have is good enough for our purposes. Otherwise, building an entirely new widget from scratch (no matter how lean), styling it to fit the app, and maintaining it will require a significant amount of work upfront and potentially in the future (bugs and whatnot).

Here are our options as I see it:

1. Take the base npm react-calendar component as it is with some additional styling on top to fit in with Astrostation (some sample styling for ya, sorry for the text I was navigating their components)
2. Patch some desired functionality on top of react-calendar by taking what they have now for 3.x and do not maintain it beyond our additions.
3. Create a leaner calendar widget from scratch.

@royanger @Melkeydev @mattprivman @creativenull Any input on this? Personally, I'd prefer to do either of the first two, as I see myself practically rebuilding react-calendar to meet our needs. I'll abide by what y'all think is best.

[royanger]

This is why I am opting to go the route I have specified above.

I think this is the heart of the miscommunication. When the npm option was first brought you mentioned dependencies and not lack of features.

Ignoring this library and really any existing solution, can you spec out the needs for the calendar? Let's get that listed and then we can discuss those needs.