Help understand ideal coupling and interaction patterns between Textual and non-Textual modules.

[aaronrudkin]

Imagine you're building an app that consists of a TUI interface to a backend data store managed by, say, without loss of generality and ORM. You probably want almost everything to do with display to be handled by the TUI, and almost everything to do with underlying data state to be handled in the ORM.

How would you structure communications between the TUI and the ORM?

First, thinking in terms of unidirectional data flow, it's actually unclear to me who the parent is and who the child is. I guess technically this is a model-view design and I could either use a controller or have the model talk to the view.

Second, just in terms of implementation details, it's sort of less clear to me if the more coherent thing to do is for the ORM to notify the app via messaging (if so, what's sending the message?), via direct method calling, or what. Also, if I want the ORM to perform some multi-threaded task, I suppose the parent thread should talk to the TUI and the child threads just communicate results to the parent thread? What about reactivity?

If anyone has an app that uses Textual and non-Textual components I'd be interested in studying the code to understand how you dealt with coupling and interaction. Thanks!

[gbtami]

You can take a look at https://github.com/driscollis/squall
It doesn't uses the ORM from sqlalchemy, but you can get some ideas how it connects the db and TUI.

[aaronrudkin]

Thanks, I appreciate it. I checked a few of the apps in the main website's gallery and this one, but one challenge is that many of the examples are cases where there's very limited model state or backend I/O.

Looking at squall, if you look at the various classes, TableViewerPane; WarningScreen; FileBrowser; ExecuteSQLPane; EditRowScreen; DatabaseStructurePane; and SQLiteClientApp are all Textual components. It's really only db_utility that's outside Textual. And it's really only the main application that can call db_utility. It appears to be implemented as a synchronous set of methods called by the TUI, with no callback or message passing beyond returning results when asked. There are a couple of async functions (though none in the DB). There's a single threaded worker function for rewriting panes in response to SQL activity. As best as I can tell, the entire data model is held in the main app.

I think this is definitely good for the Textual side because it enables unidirectional data flow, but it's difficult to think of how to scale that to cases where there's something more like a model+view design and where it's actually important that the non-Textual components be managing things a little more.

Anyway, I'll keep looking through the examples and hopefully I'll end up wrapping my head around the architectural possibilities.

[gbtami]

I suggest to join the textual Discord server (in case you are not there already). There are lots of experienced textual people there who can possible give you some better examples/ideas.

[aaronrudkin]

What I ended up doing in terms of coupling...

• Implement unidirectional data flow within the TUI side, attributes down, messages up.
• Only the main application is allowed to communicate with the non-TUI, source-of-truth, data manipulating side
• Main app and the non-TUI modules store reciprocal references to each other to enable coupling
• Main app talks to non-TUI modules by calling their methods (as it happens they're async so via asyncio tasks)
• Non-TUI modules communicate with main app by writing to main app's reactive attributes.
• Data binding links main app reactive attributes to child widget reactive attributes as necessary; a watcher handles a few cases where it makes sense for the main app to be doing more dispatching.

I'm pretty happy with how it turned out. Definitely it's a little weird that child-parent TUI communication sends messages and non-TUI -> TUI communication writes to reactives to trigger watchers, but I think the alternative of creating a siloed off message dispatcher to keep everything through the message system is worse.