In developing the structure of my app, a primary goal is finding ways to encapsulate functionality and prevent redundancy. Custom workflows in reusable elements seem like a good idea, but have their limitations. API workflows seem promising, especially if the work they’re doing is independent of the client. However, they have limitations that differ from custom workflows in reusable elements.
Here’s a specific example of where effectively encapsulating functionality would be desirable.
An Action (i.e. “to-do”) has been completed. It is a recurring Action so a copy should be created with a Date Due in the future. The act of marking the Action as done can happen in any of several places in the UI. This is obviously an ideal situation for encapsulating all the work of updating the Action as done and creating the new, future Action.
There is no need for the user to be held up while this is being done, so it seems like an ideal candidate for an API workflow. And, because an API workflow has defined parameters, it’s a perfect case for defining the interface for good re-usability. However, there seems to be a problem with this.
- API workflows don’t support custom states. Therefore, the logic for calculating duration of the completed Action and determining the future date for the next Action are impossible to do, or at best, very unwieldy.
Is there a way to implement this kind of functionality in an API workflow? In an effort to avoid replicating “code”, is there another approach for encapsulating this functionality?