Do people have best practices, source control, or ways to ensure resuability and consistency of expression bindings?
We're heavy users of expressions, particularly since @pturmel's Integration Toolkit provides expressions that are much more performant than python functions. So it's common we'll have a view with many complex view.custom.* properties that ingest and handle data within our UI elements.
But this creates a few stresses:
We may have multiple similar views that have nearly-identical custom prop expression bindings to pull items from a cache/varMap, create a list of tag members and/or properties, query in one call with the tags() function, and remap the results into data objects usable by components. But since these are expressions and not python, we can't outsource them to a project library.
It becomes a manual task to identify best practices within our expressions, the latest and greatest for a particular use, and sometimes determining the flow of operations within a group of view.custom props bound to other props.
While we've learned the wisdom of the AHA/Avoid Hasty Abstraction principle and don't have problems duplicating logic, we still strive for DRY/Don't Repeat Yourself where possible.
Edit for additional nerd snipe: One dream is to have something like Excel's Lambda function, where I could create a project library of expression functions with custom parameters and handling.
There's definitely the kernel of an idea there, an "expression library" or something. There's nothing, technically, preventing us from doing it, but I'm still not totally sure it passes the -100 points rule.
I can immediately think of at least four more-and-less significant drawbacks:
added complexity for less advanced users
"competition" with runScript
possible confusion of maintainers having to distinguish system expression functions, module expression functions, and user provided expression functions
interaction with (far) future plans for expression/scripting interpreting in Ignition
Are those worth the added maintenance benefits to large scale systems trying to DRY things out? I'm not convinced yet, and the default position is "don't".
I'm actually already working on this as an "Expression Resource/Expression Library" concept and have it "Mostly Working".
I don't think it would compete with runScript, and here's why. runScript is intended to run a "script", where this would be evaluating an "Expression".
I've thought about this myself, and have some ideas. But it requires a designer workspace tailored for the task of managing per-project names, and I'm not interested in tackling that until after v8.3 comes out.
Still curious if anyone has suggestions on managing a library of expressions in the meantime. My current situation - a text editor window with lots of unsaved, uncommented blocks of expression code - is not quite cutting it.
We've got a Bookstack instance we use for a company-wide Wiki that we can add stuff to for commonly used scripts, etc. It works better than some wiki software due to the "forced" use of books, chapters, pages organization that's built-in.
We're on our way to Bookstack. We're currently using the docs in our not-to-be-named project management saas product that unfortunately feels adding AI buttons everywhere is better than making their product fast and bug free.
I've also used Obsidian and LogSeq for a markdown/notetaking IDE on local files, though as mentioned upthread I get lazy and just paste into a text editor. Ideally any solution would be easy/scriptable to output actual markdown for compiling to pretty PDF or a static site generator (e.g. our external product documentation).
Bookstack also has a nice code formatting editor built-in with a lot of languages (more than I can fit on my screen) and direct integration with draw.io / diagrams.net for making diagrams:
