Replies: 3 comments 2 replies
-
|
#31 is a good example of how not taking an object route will become increasingly challenging to maintain: large function specs and tricky required/option/default value parameterization, which is inherently brittle. |
Beta Was this translation helpful? Give feedback.
-
|
@CalvinChanCan , @grablair , curious for your thoughts on this proposed refactor. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for drafting this, @hammem! Sorry for the delay, I was on vacation. Initial thoughts:
In this new world, would a user not call the Mostly I think the design looks good to me. I like the idea of modeling these types, and allowing users to set some of the most commonly changed values via methods that are discoverable in things like I do think we could pass off some of the code from I'll think about this a bit more. Thanks again! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Looking for feedback and thoughts on this as the API grows and we have more folks touching the code. Want to make it easy to keep expanding, help folks avoid errors, and prevent from having a utterly unmaintainable
MonarchMoneyclass.Why bother?
As the API grows, we've started to move into mutations. With that, comes the increased chance a user accidentally edits something they didn't intend, creates a bunch of things by mistake, or (worse) deletes things they weren't intending to.
To help with this, as well as the maintainability of the codebase, I'm proposing to make the following changes:
MonarchTransactionclass, with aMonarchObjbase for other things like budgets and accountsThe key would be to keep them light-weight. Not looking to go fully schematized, since staying in sync with Monarch won't be trivial. But, rather, strike a balance of enabling static analyzers to help you from making mistakes without making it feel onerous to use.
MonarchObjThis would be the base object for all return types.
Dictto provide a Pythonic experienceMonarchTransactionMonarchObjupdate_tags)How
MonarchMoney.pywould changeAs a result of this, function return types would start undergoing the following changes:
async def get_transactions(...) -> Dict[str, Any]becomes...
async def get_transactions(...) -> List[MonarchTransaction]Other thoughts
We could go 'all in' and also create ID types, to help with statically determining if code is handling the 'right' type of ID for a transaction. But, at this point, that's probably too much overhead.
Beta Was this translation helpful? Give feedback.
All reactions