v5 documents completely change how lifecycles work, not documented as a breaking change about documentation HOT 13 CLOSED

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).

from documentation.

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)

from documentation.

We will add them in the beta docs soon but in the meantime you can do what is mentionned in strapi/strapi#19998

from documentation.

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

from documentation.

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

from documentation.

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.

from documentation.

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.

from documentation.

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

from documentation.

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.

from documentation.

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

from documentation.

@derrickmehaffy it's in here #2074

from documentation.

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

from documentation.

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

from documentation.