search

spatie / opening-hours

Query and format a set of opening hours
https://freek.dev/595-managing-opening-hours-with-php
MIT License
1.65k stars 116 forks source link

Supporting frontend library #242

Closed Azeirah closed 3 months ago

Azeirah commented 8 months ago

Hi! We're using this package in production, and it's great! However we have situations where it makes sense to calculate the opening hours in the frontend as well

For instance, we use the library to check whether products can be ordered at certain times. Our menus have an OpeningHours object, and a product can be linked to multiple menus. Sometimes a product like "morning breakfast" is available only in the mornings, and we need to recalculate its availability when refreshing the app for instance, it's wasteful to go through the backend for this.

It's not high priority at all, and I already have some shoddy code in the frontend to parse and process OpeningHours, but I think it would be nice to formalize it a bit further and maybe eventually add it to this package as a small drop-in supplement.

kylekatarnls commented 8 months ago

Hello.

I don't see how it could be "a small drop-in supplement", reading your message sounds to me like you're asking the whole library to be rewritten in JavaScript so it can be used browser-side also. The idea is interesting but IMO it should not spatie/opening-hours library responsibility, It should be a separated repo provide some npm package which can be maintained autonomously from the PHP package.

Azeirah commented 8 months ago

I'm not asking for the whole library to be rewritten. To be clearer, I'd like a small client-side library that understands the spatie-openinghours format to support the isOpen() and isOpenAt(date: Date) functions.

I don't think this is a big undertaking, and since I'm the first one even asking for it I don't think there's a lot of demand for all the other functionality. Additionally, once I get the the part where I have to formalize our own code a bit further, I'm offering my time to implement such a minimal supplementing package for this repository myself.

I opened the issue to discuss whether such a package is desirable at all, and what should be in it, and if there are any pitfalls to watch out for if it's desirable to release it to the general public (such as: should it support alternative date/time packages such as moment.js and date-fns?)

kylekatarnls commented 8 months ago

I'm offering my time to implement such a minimal supplementing package for this repository myself.

This is very kind of you. 🙏

I still prefer to warn about the seemingly small size of this task.

understands the spatie-opening/hours format

This is roughly 75% of the code of the library, it has days of the week and time but also time range, day ranges, exceptions that can be defined by multiple formats of date (on exact year or on every year), filters, it has options such as the timezone, the overflow to allow a range to overlap on the next day (night opening).

About the purpose being generic enough: implementing only 1 or 2 methods is not decreasing significantly the complexity of the task, and if choosing to implement only some part of the format but not all, some of the options but not all and some of the methods but not all, it would just sound like an unrelated library and I think (but it's pure guessing) it would not be a lot of demand.

However I can completely understand it could be enough for some businesses.

Having a full JS equivalent of the library however could interest way more people but that might be tedious. Depends how much spare time you have available (or if you know companies interested in that may sponsor the development of such a library).

I would definitely support an initiative from any developer willing to build a JS library that can interact in a compatible manner with this library and I would probably give a hand.

Azeirah commented 8 months ago

This is roughly 75% of the code of the library, it has days of the week and time but also time range, day ranges, exceptions that can be defined by multiple formats of date (on exact year or on every year), filters, it has options such as the timezone, the overflow to allow a range to overlap on the next day (night opening).

These are some good points, we only use a relatively small subset of the library on the frontend. Basically only timeranges and exceptions, we handle timezones in our own heavily convoluted way (which is why I thought it'd be nice to formalize it!)

I don't have the time to author a feature-rich library, and the company I work for won't be able to sponsor it for sure.

That being said, we do rely on these features in our frontend to an extent, and we do use Spatie libraries extensively (and I use them in my own projects too) so I am willing to spend some time on this.

I think it's best to gauge what kind of demand there is at all for this, and if it is the case that more businesses want this I do think I'd be willing to be involved in a collaborative effort.

About the purpose being generic enough: implementing only 1 or 2 methods is not decreasing significantly the complexity of the task, and if choosing to implement only some part of the format but not all, some of the options but not all and some of the methods but not all, it would just sound like an unrelated library and I think (but it's pure guessing) it would not be a lot of demand.

Given that we kinda have this in our codebase already anyway, I might as well just refactor it out into its own package when I'm working on related tickets to clean up our codebase. It could act as a starting point for developing a more fully-featured library.

spatie-bot commented 3 months ago

Dear contributor,

because this issue seems to be inactive for quite some time now, I've automatically closed it. If you feel this issue deserves some attention from my human colleagues feel free to reopen it.