feat: add discriminator helper

[jbool24]

Allow extension and inheritance of base models with discriminator models.

[arashsheyda]

@jbool24 thanks for this! this is such a good idea. but do you think we can have it in the defineMongooseModel as an optinal param? like:

return baseModel ? baseModel!.discriminator<T>(name, newSchema) : mongoose.model<T>(name, newSchema)

[jbool24]

@arashsheyda I don't have a good reason why not. But I was just trying to keep things separated instead of using internal flags to manipulate what the factory outputs. Your lib, your choice :smiley: :+1:

[arashsheyda]

@jbool24 sorry for late reply, I think becuase they share a lot of similarities it's better to do it that way.

ps. it's an open source lib so we can talk about it :) it's not my choice only

[jbool24]

@arashsheyda In that case :smile:, my two-cents is keeping the two factories discrete from each other because...

• I'm personally not a fan of optional input params (in JS especially) and branching logic in factories. Discriminator instantiation hangs off the base model and that requires the extra base model to be passed in but not for a normal model. Maybe if the options require a mandatory "type" as the switch for the desired from the output? But I don't know why, it just feels yuk to me. :man_shrugging:
• Discriminators are not used often but very powerful when it fits a domain model. So just keeping it all bundled in one factory seems unnecessary because the use case is not so common.
• if the factory only outputs one thing without branching logic, no surprises. Pure function and we get exactly what we expect.
• Unless the function name is changed it could be unexpected without looking at documentation.
• With one factory the Typescript defs need to include conditionals to "choose" types between which one the user is expecting. Maybe not a big deal but I like simple when it comes to Typing defs :laughing:

I'm open to hear why combining them would be good also.

[arashsheyda]

@jbool24 well here are my thoughts for having it as Combined Factory Function:

• Simplification of the API: Combining both regular models and discriminators into a single function simplifies the API surface for users. They only need to learn and remember one function for creating both types of models.
• Reduced Potential for Errors: Having one function reduces the potential for errors and inconsistencies that may arise from managing two separate functions. It promotes DRY (Don't Repeat Yourself) principles, reducing duplication and improving maintainability.
• Potential for Readability: While optional parameters and branching logic can introduce complexity, a well-designed combined function can maintain readability with clear documentation and appropriate naming conventions.

but as you said having it as Separate Factory Functions has it own pros too!

• Keeps the functions focused and specialized, reducing complexity and potential confusion.
• Makes the API more explicit, as each function has a clear purpose.
• Avoids branching logic and optional parameters, potentially leading to cleaner code.

🤔

[RodrigoRoy]

As a regular (not so specialized) Mongoose user, I prefer the ideas for a Separate Factory Functions. I just want a new function that allow me to create a Discriminator, otherwise, I aggree that it is kind of confusing.

[arashsheyda]

@jbool24 thank you!