concept check on features, jobs and operations

[bdelamatre]

I am architecting an app, using Lucid to reference some ideas. Unfortunately, I am stuck in a feedback loop and I am curious how others think this might fit into Lucid's concepts.

1. I need to submit an order through a web form.

To accomplish that I have a SubmitOrderFeature. This feature upserts an order (UpsertOrderJob) and then runs a number of services for that order (UpsertOrderServicesOperation). So far, so good.

2. I need to submit an order through an API endpoint.

I abstract the request input on SubmitOrderFeature to accept a generic request whether it comes via the web or API. I then add SubmitOrderFeature to my API endpoint passing in the API request input. So far, so good.

3. I need to submit a CSV file containing a collection of orders. Each line of the CSV corresponds to an order. This is where I start to have trouble with Lucid.

In order to accommodate the upload I add a SubmitOrderUploadFeature. This feature needs to loop through each line and call the equivalent of SubmitOrderFeature on that line. Well, according to Lucid I shouldn't call SubmitOrderFeature from SubmitOrderUploadFeature. Okay, so I effectively take the contents of SubmitOrderFeature (a job and operation) and duplicate it inside SubmitOrderUploadFeature inside my loop. I don't love it, but I am only calling jobs and operations inside the new feature.

4. Okay, now Lucid seems to really break down on my next need. I need to be able to re-submit a single line from the CSV.

What I would like to do is have a SubmitOrderUploadLineFeature. But the result of this feature is effectively the same as what's called inside of SubmitOrderUploadFeature. So now, I have to duplicate code again from SubmitOrderUploadFeature because:

a) I can't abstract into a Job or Operation because each line is calling UpsertOrderJob and UpsertOrderServicesOperation because they are both jobs
b) I can't have SubmitOrderUploadFeature call SubmitOrderUploadLineFeature because they are both jobs

The result seems to be a bunch of duplicated code fragments, which I would say is probably worse than having one feature call another feature or one job call another job.

Thoughts?

[Mulkave]

@bdelamatre this is such an interesting case you ran into. I could think of an approache that i wish can help inspire you to come up with a solution to write the code once and reuse the parts that are needed. But before that, I would like to highlight that Lucid isn't here to incur constraints, you can do what you want with your code but the guidelines are there to help you keep it concise. All possibilities of PHP itself still exist so you may do whatever you like with the units you are writing.

Use inheritance (OOP)

Create a parent (abstract) feature SubmitOrderFeature from which the rest of the features descend. In its handle method you run UpsertOrderJob and UpsertOrderServicesOperation (given that these are the only two common steps you need to perform).

Then you create SubmitOrderUploadFeature extends SubmitOrderFeature and add a job that parses the CSV and turns the line into a request's input or whatever format SubmitOrderFeature::handle accepts, then loop through them by calling parent::handle inside
SubmitOrderUploadFeature::handle. The same would happen for SubmitOrderUploadLineFeature.

So it goes as such:

SubmitOrderFeature

• UpsertOrderJob
• UpsertOrderServicesOperation

---

SubmitOrderUploadFeature extends SubmitOrderFeature

• ParseCSVJob
• Foreach line in result
  • ConvertResultToInput
  • parent::handle($input)
    • UpsertOrderJob
    • UpsertOrderServicesOperation

---

SubmitOrderUploadLineFeature extends SubmitOrderFeature

• ParseOrderLineJob
• Foreach line in result
  • ConvertResultToInput
  • parent::handle($input)
    • UpsertOrderJob
    • UpsertOrderServicesOperation

Or you can extend SubmitOrderUploadFeature instead and wrap the single line with a CSV resource:

SubmitOrderUploadLineFeature extends SubmitOrderUploadFeature

• WrapLineWithCSVJob
• parent::handle($csvWithOneLine)

---

This approach works only when there's a high degree of similarity between the features that you're calling, which is the impression i got from your post. If this doesn't work please let us know here so we can explore the case further.