v5 documents completely change how lifecycles work, not documented as a breaking change

[laurenskling]

in v4, a entry gets created as a draft (beforeCreate/afterCreate) and published (beforeUpdate/afterUpdate). All changes afterwards are beforeUpdate/afterUpdate

in v5 we have documents. Multiple entries per document. What happens now is:

create a document in draft (beforeCreate/afterCreate). Save the draft (beforeUpdate/afterUpdate). Publish the draft (a beforeUpdate/afterUpdate on the draft and a beforeCreate/afterCreate on the published entry).

When i now start changing the draft and publish it, the following sequence happens: beforeUpdate/afterUpdate on the draft. beforeDelete/afterDelete on the old published entry, beforeCreate/afterCreate on the new published entry.

This completely changes the way how lifecycles are working in v4. I now have way more create events, and even worse, I now have delete event which were not actual deletes of the (now..) document. All my current lifecycles need a complete rework, if this is the way forward. It is not documented in the breaking changes, which is really a big one for me, because I'm pretty sure people use lifecycles for a bunch of things that are really going wrong right now.

I really hope this is an oopsie and lifecycles would actually be triggered by events on the document, not on the entries of the document. Making lifecycles not a breaking change. Is it so?

[derrickmehaffy]

While this doesn't follow our required template I'm letting this one bypass our rules as a discussion.

Is a topic for @alexandrebodin / @Marc-Roig / @innerdvations to get their thoughts

[alexandrebodin]

Hello,

Database lifecycles cannot be turned into document lifecycles as they are not operating on the same level and have a DB level API. Their API isn't broken as they are called on DB events correctly. We will definitely have to add a notice that with the new D&P feature more events on DB will get triggered 👍

That being said will need something else to know the higher level events that are happening on the document that you couldn't before (publish/unpublish etc) We are looking into adding document level lifecycles to offer what you are looking for but this will need to have a different api as you won't operate on the db level. If you have suggestions on how and what you would needthat would be very helpful.

[laurenskling]

Yes, a notice would be very very welcome.

Examples of things I do in lifecycles: Create:

• fix user input, f.e. slugify the slug field.
• find relations based in input data
• fetch external services, based on given input data, and set the reponse data on other fields
• email owners that new entries have been created (form submissions, etc)

Update:

• fix user input, f.e. slugify the slug field.
• find relations based in input data
• see if the slug changed and add a entry to the redirects repeatable component

Delete:

• delete cdn files when entry gets deleted
• delete redundant relations that are only needed for my specific entry

Actually the current db lifecycles are pretty difficult to work with, as they get the "whatever it has been called with" event. I've written about this before. I have to handle all cases the lifecycles might be triggered from (f.e. is it a relation: [1] or a relation: { connect: [{ id: 1}] }?). Or f.e. deleting many cdn files, I have to do it in the before, because in the afterDeleteMany I only receive: "the deleteMany function has been called with the filter: ...", which I now cannot use to find them because the entries have already been deleted, so I have to use the beforeDeleteMany lifecycles, to still be able to query all the entries beforehand.

I would way more prefer a lifecycles workflow that can tell me things like: "going to delete [{ }] because {}" and "delete has been called on [{ ... }] because {}". If document lifecycles to make this happen, it will make developing lifecycles so much easier (to understand).

[derrickmehaffy]

The documentService lifecycles will be more useful than the current db lifecycles as they are a few layers of abstraction higher. I was trying to do some testing of them today though (see the related bug report) and they are currently broken but I'm chatting with Alex and Marc internally about it.

[laurenskling]

@derrickmehaffy you think will they land in 5.0.0? (so I can wait for it and forget about current lifecycles)

[derrickmehaffy]

Oh yeah they will, just have to squash out the bugs and get them documented (I did have to check and indeed they were not documented, likely because @pwizla was not aware they existed)

[derrickmehaffy]

I'm not sure what all is possible with them but from what I can see in the code they are wrapped around the documentService functions and have a ctx and a next just like normal route middlewares so you should have access to everything in the ctx and I assume make modifications to it.

[alexandrebodin]

We will add them in the beta docs soon but in the meantime you can do what is mentionned in https://github.com/strapi/strapi/issues/19998

[derrickmehaffy]

I'm going to move this over to the documentation since it's not really a "bug" per say but once we document the document service lifecycles we should probably classify it as a breaking change and show the difference between lifecycles and docsrv lifecycles

[derrickmehaffy]

@pwizla once you get the info to document the docsrv middlewares poke me and we can help write the breaking change info.

[alexandrebodin]

@derrickmehaffy it's in here https://github.com/strapi/documentation/pull/2074

[pwizla]

The various database lifecycle hooks triggered by the Document Service API methods are now documented here: https://docs-next.strapi.io/dev-docs/api/document-service/lifecycle-hooks

[pwizla]

(and Document Service API middlewares are documented here: https://docs-next.strapi.io/dev-docs/api/document-service/middlewares)