Hey everyone, new YouTube tutorial is up where I walk through how to set up a Tulip app step that might be repeated in many apps as a centralized, separate application. The video goes over the most basic example possible, but the concept can be extrapolated in many ways to start thinking of your Tulip apps as a connected web, instead of many separate apps. The entire video is almost entirely done in one cut, which I think is helpful to learn some of the small details that go on in a Tulip app building process. Please let me know if you have any suggestions for future content
Hey @danielpomeranz - thanks so much for sharing this!
I can see how this is helpful because now you only have to manage/update your defect log in one place, even if you use it in many apps. The con here being having to create that abstract table to manage sharing information across apps.
The filpside of this, putting the defect log step in every app where defects need to be reported, keeps everything in one flow for the user, and they don’t need to be interrupted and cut into a different function. However, if someone wants to change something within the defect logging logic, they will now need to update it in every application where the module is used.
I hope Tulip will eventually provide native support for running other apps “on top” of a main app. This would make development much more efficient and less convoluted.
And each app should have access to the other apps last state after a jump has occurred and have access to or reference a copy in the log.
The completions could still be logged individually per app in addition to that.
That would open a new world because you could offload common tasks to dedicated apps or “modules” that together then build an entire app.
The “workaround” suggested in the video currently breaks the single trail record idea.
@Beth: Any chance we might see something like this in the near future?