Closed schimini closed 11 months ago
Hii @LuisRodriguezLD does this interest you or should i close it?
Hey @schimini, thanks for your contribution. I love the idea of integrating plugin fields and I definitely see the use case
However, the current state of this PR includes a lot of code style changes, eg:
- import React, {memo, useState, useEffect} from "react";
+ import React, { memo, useState, useEffect } from "react";
This was probably my fault given I don't have prettier configured but right now this makes the PR hard to review. Any way we can remove those types of update?
Again, thanks for all of this
Hi, no worries! Why don't we do both separately? I can help you setting up eslint config or prettier or other tool you're comfortable with for this project and after that I can make my PR use the same as code styles making the review easier.
Having code styles is always a good thing :)
(Alternatively I can revert my changes in a way that don't mess with styles and still keep the functionality but that would take me a while)
What do you think?
On Mon, Jan 9, 2023, 23:39 Luis Rodriguez @.***> wrote:
Hey @schimini https://github.com/schimini, thanks for your contribution. I love the idea of integrating plugin fields and I definitely see the use case
However, the current state of this PR includes a lot of code style changes, eg:
- import React, {memo, useState, useEffect} from "react";
- import React, { memo, useState, useEffect } from "react";
This was probably my fault given I don't have prettier configured but right now this makes the PR hard to review. Any way we can remove those types of update?
Again, thanks for all of this
— Reply to this email directly, view it on GitHub https://github.com/offset-dev/strapi-calendar/pull/20#issuecomment-1376496357, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACN4CJYDFTYIL3K7GB5DTATWRSOSDANCNFSM6AAAAAATCZIRRA . You are receiving this because you were mentioned.Message ID: @.***>
Hey, now that we have prettier configured, could you update this PR?
@LuisRodriguezLD done (and I also fix a major bug with my publisher plugin integration that I don´t even know how I didn´t notice earlier). A good takeaway from this experience is that if/when strapi-calendar gets big you guys should invest some time into tests, maybe there should be rules about the PRs (to what branch, etc). But for now, it's a good strapi plugin and thanks for making it!
I was thinking of expanding this behavior for https://github.com/webbio/strapi-plugin-scheduler as well . It's the one used on the foodadvisor app.
Hi @LuisRodriguezLD any news on this?
Hi all, @pr0gr8mm3r , @marcjoancr , @Carababusha , @LuisRodriguezLD , sorry to bother you , is there any change this gets merged this month? I don't want to put a timeline on this, i just wanted to know if I need to do local shenanigans to have this working on a personal project or not ;)
Hello Schimin; I've been quite busy lately and haven't had the chance to look deeper into this. The one thing that is throwing me off is having a new plugin (Publisher) within a plugin (Calendar).
Hi @LuisRodriguezLD no problem. Sorry it took me a while to implement, but I've changed this a bit. So: I totally understand not wanting to have other plugin related stuff in this project. That's why I've implemented a basic extension system. The logic within strapi-calendar is cleaner and it now allows everyone to extend the calendar to use custom start and end fields (being it based on other plugins or not). The usage of this system on the user end would be (for integrating with the publisher plugin):
// ./config/plugins.ts
export default ({ env }) => ({
publisher: {
enabled: true,
},
calendar: {
enabled: true,
config: {
extensions: [{
id: 'plugin::publisher',
name: 'Publisher plugin',
startFields: [
{
id: START_FIELD,
type: 'datetime',
displayName: 'Publisher plugin start',
},
],
endFields: [{ id: END_FIELD, type: 'datetime', displayName: 'Publisher plugin end' }],
startHandler: async (date, entityService, config) => {
const data = (
await entityService.findMany(PLUGIN_CONTENT, {
filters: {
entitySlug: { $eq: config.collection },
mode: {
$eq: config.startField === START_FIELD ? 'publish' : 'unpublish',
},
executeAt: {
$gte: moment(date ?? moment())
.startOf('month')
.subtract(1, 'month')
.format(),
$lte: moment(date ?? moment())
.endOf('month')
.add(1, 'month')
.format(),
},
},
})
).reduce((acc, el) => {
acc[el.entityId] = {
[config.startField]: el.executeAt,
};
return acc;
}, {});
return merge(
data,
// Fetch base fields
(
await entityService.findMany(config.collection, {
fields: ['id', config.titleField],
filters: { id: { $in: Object.keys(data) } },
})
).reduce((acc, el) => {
acc[el.id] = el;
return acc;
}, {})
);
},
endHandler: async (entityService, config, data) =>
(
await entityService.findMany(PLUGIN_CONTENT, {
filters: {
entitySlug: { $eq: config.collection },
mode: {
$eq: config.endField === END_FIELD ? 'unpublish' : 'publish',
},
entityId: { $in: Object.keys(data) },
},
})
).reduce((acc, el) => {
acc[el.entityId] = {
[config.endField]: el.executeAt,
};
return acc;
}, {}),
}]
}
}
});
or
// ./config/plugins.ts
import * as strapiCalendarPublisherExt from "strapi-calendar-publisher-ext"
export default ({ env }) => ({
publisher: {
enabled: true,
},
calendar: {
enabled: true,
config: {
extensions: [strapiCalendarPublisherExt, <others>]
}
}
});
This allows everyone not only to use custom implementations but also to provide this extensions as npm packages for others to use. Hope this is a better approach.
Also i named it extensions because plugins could be confusing since strapi-calendar is already a plugin
@LuisRodriguezLD bump
Hi all, @pr0gr8mm3r , @marcjoancr , @Carababusha , @LuisRodriguezLD , sorry to bother you again. do you need anything else for this to go through?
@LuisRodriguezLD bumping
Hi all! I'd love to see this merged too. This feature fits perfectly with the awesome calendar you built, and I think @schimini made a great work to polish this PR. If I can be of any help, be sure to ping me :)
Hey everyone, this also meets exactly my needs! Thank you @schimini for your great work! When can we have this available @LuisRodriguezLD?
Hi! I did this for me in a few hours today and wanted to share it in case someone wants the same functionality.
The idea is to allow strapi-calendar to use other plugin fields. This PR includes a basic integration with the publisher plugin.
My use case was to add events to the calendar based on the future scheduled posts.
If this is not wanted within this library disregard this PR :) Otherwise if the PR needs some modifications, tests, or docs let me know !
PS: While double checking my modifications I remembered I also fixed a small deprecation issue related with moment's usage. The format ll shouldn´t be used to construct a moment object and it was. ( the warning was: moment deprecation warning value provided is not in a recognized rfc2822 or iso format )
Thanks