'Nodes' accessing other Nodes' properties

Feedback Feature Requests
1

Continuing the discussion from Introducing NewTags (with examples):

This is something I’ve been thinking of for a while now. I’ve often thought how useful it would be able to reference the properties of other nodes (formerly pages and blocks but I’m thinking forward).

A simple example being if you have an audit coming up on a given date.

  • Quarterly Audit May-July
    Scheduled: 20th March

You might need to prepare for that audit

  • Quarterly Audit May-July
    Scheduled: 20th March
    • TODO Prepare
      • Check unique request from Manager
      • Collate paperwork
      • etc

Now you ideally want the prep job to have a deadline of the date of the audit (at least lets say you do for this example)

Hence:

  • Quarterly Audit May-July
    Scheduled: 20th March
    • TODO Prepare
      Deadline: 20th March
      • Check unique request from Manager
      • Collate paperwork
      • etc

But just as obvioulsy it would be both easier to enter and futureproof (if the audit date happens to change) if you could link the TODO deadline property to the Scheduled deadline of a given node (in this case the parent node.)

In addition I think with dates in particular being able to perform operations on the referenced property would be really useful so that you could set the deadline of preparing the information to say 3 days before the scheduled date of the audit.

I’m not a programmer but having done a bit of programming it feels like logseq appeals to that mindset and that being able to reference properties in a similar way to Java would be quite intuitive. i.e. Node 2 deadling: Node 1.scheduleddate.
I’m writing in Psuedocode just so it’s easy to read so please excuse the obviously incorrect formatting etc. It’s just for readability.

Other examples might be…

  • Setting the priority of one task by that of another so they’re synched in case you adjust the importance of a project because of changing circumstance.
  • Setting the contact phone number property of a ‘Person’ node to the phone number property of a ‘Company’ node (see this question)
    • Or even setting it to the phone number + an extention number.
2

Very useful, but not simple at all. Accessing values other than the typical dynamic variables requires to define some language, which is essentially scripting (whether in text form or wrapped by some plugin). But if Java and pseudocode are considered intuitive, better use the full power of custom.js, kits and Synthesis.

3

Thanks for answering me @metaloid I really appreciate it.

i remember looking at kits a while back and this is a good reminder to come back to them. Thank you for working them out for us.

I’ve been reading the instructions. And as far as i can tell I can’t make a kit something that updates every time a certain specific node updates so it would only fire once. I mean I might be able to if I were an expert but there’s no way to use kits to check and update as needed. Bearing in mind that the idea is that there would be lots of linked properties in theory so I wouldn’t want to burden the systme with constant checks.

Obviously it would be useful to have the system do it the first time as well don’t get me wrong. I just wanted to check if I’m missing somethin.

4

Macros run on every rendering of their block. Here are two approaches:

  1. Triggers on rendering of dependent nodes.
    • Relatively easier to implement.
      • But if you query such a node before it gets rendered/synced, it may still hold an old value.
    • On every node that depends on other nodes, add:
      • a property that describes those dependencies
        • i.e. whatever data the following kit may need to perform the update
          • This totally depends on the particular needs.
      • a macro (e.g. CheckDependencies) that runs a kit that:
        • reads the dependencies property
        • updates the current node’s properties (or even its content) accordingly
  2. Triggers on rendering of dependency nodes.
    • Relatively harder to implement, but it covers more scenarios.
    • On every node that depends on other nodes, add a property that describes those dependencies.
      • Same as above, but it should additionally include a reference to each one of those nodes.
        • This is in order to be queried on the next point.
    • On every node that other nodes depend on, add a macro (e.g. SyncDependent) that runs a kit that:
      • queries for nodes that reference this node
      • for each found node:
        • reads its dependencies property, looking for the reference to the macro’s node
        • updates its properties (or even its content) accordingly