add a contributing.md file for the calendar-widget package

[Ngoakor12]

Some things that would be helpful to include:

• pnpm is used/needed to contribute
• getting setup on your machine(which commands to run in which order)
• and other general guidelines on contributing

side note: nice looking project by the way, I like the idea list , I was also working on a somewhat similar package along these lines because of my frustrations in working with the date and times

[matthewbub]

@Ngoakor12 thank you for taking the time to put together these suggestions - it's incredibly helpful to see from a fresh perspective. I'll get the ball rolling on the contributing guide ASAP 🙂

That is some slick stuff in that date-time-utils package. It might be super slick to mesh these projects into 1 🤔🤔🤔

[Ngoakor12]

That is some slick stuff in that date-time-utils package. It might be super slick to mesh these projects into 1

I'm definitely down on two conditions: you lead the way forward(cause I think I'm less experienced with npm packages in general, same with typescript and never touched rollup) and I can have most if not all of the functions in date-time-utils

My main idea behind the project: provide well named wrappers/some abstractions for date and time related logic. Add related but missing helpers as and when needed.

Side note, I really like the idea of adding custom well written errors to these helpers.

[matthewbub]

Sure that sounds great to me! My only request is that we maintain a goal of consistency across each utility. Everything available to the public should be type-checked, throughly tested, documented and JSDoc'd. I am happy to help with that process and share my knowledge, it's ultimately just JavaScript with extra steps 🙂 !

The main reason I request consistency is to avoid damaging the packages reputation with community comments such as these:

My long term vision for this package is not in the utilities themselves but in the "widgets" that can be built from these utilities. React is my lang of choice so I figured starting there and seeing how the community feels about it after.

Here's the one i really want personally, and the main driver of inspiration for me behind the project (the draggable date-events) 🤩 :

But I figure if something of that scale is going to be built, we might as well cover all the groundwork needed to get there anyways. e.g

If your down, i'm down! We can connect on discord if you use that https://discord.gg/4qArE7Z4mC

I think the easiest way to begin would be via a GH issue-based approach. Each merge request, ideally should be tied to a issue that solves a specific problem.

[matthewbub]

My main idea behind the project: provide well named wrappers/some abstractions for date and time related logic. Add related but missing helpers as and when needed.

Agreed! It sounds like we've got a shared vision here 🤝

[Ngoakor12]

Sure that sounds great to me! My only request is that we maintain a goal of consistency across each utility. Everything available to the public should be type-checked, throughly tested, documented and JSDoc'd. I am happy to help with that process and share my knowledge, it's ultimately just JavaScript with extra steps slightly_smiling_face !

Consistency is my middle name :slightly_smiling_face: . Testing and Documentation should not be a big issue as well

The main reason I request consistency is to avoid damaging the packages reputation with community comments such as these:

Makes sense... mistakes happen, but responding to those mistakes in a helpful and transparent manner is important(er)

[Ngoakor12]

My long term vision for this package is not in the utilities themselves but in the "widgets" that can be built from these utilities. React is my lang of choice so I figured starting there and seeing how the community feels about it after.

Here's the one i really want personally, and the main driver of inspiration for me behind the project (the draggable date-events) star_struck :

I see. Question... are the widgets really the end goal or is the end goal really to create your own calendar? I'm asking because if the widgets are the end goals then the main users would be people who want to create calendars, parts of it?

If your down, i'm down! We can connect on discord if you use that discord.gg/4qArE7Z4mC

I think the easiest way to begin would be via a GH issue-based approach. Each merge request, ideally should be tied to a issue that solves a specific problem.

Sounds good to me

[matthewbub]

Great question, I have no desire to build a calendar for personal use. The end goal is to provide others with an SDK that addresses the complexities of Calendars and Calendar like behavior, as un-opinionated as possible. It's also got to be dead-simple to use, of course 😎

For example: referring to this img:

I invision the calendar widgets package having something like this available to the user:

<CalendarWithMeta
    dayComponent={({day, isCurrentDate, ...moreThatIHaventConsideredYet}) => (
        <div style={{background: isCurrentDate ? 'blue' : 'green'}}>
            {day}
            My Custom Day Component
        </div>
    )}
    // ... more custom props as needed or requested by community
/>

All the names used in that example are subject to change of course. The React component this package would provide in this instance would be a calendar that is as un-styled as possible.

the main users would be people who want to create calendars, parts of it?

Yeah that is correct. I haven't found a package similar to whats being suggested here online, although there totally could be one. There is a (paid) competitor to this functionality here: https://www.usemotion.com/ and I also use it in Jiras on-prem services. I figure this could open doors for a niche features & products for others to build.

[matthewbub]

@Ngoakor12 contributing guide has been created. If you happen to encounter any troubles during setup, feel free to reach out I am happy to assist however I can 🙂

[Ngoakor12]

no problemo, I'll have a look later today :ok_hand:

[matthewbub]

marking this as closed as it seems that #87 will pick up what has not been covered here