LDflex is meant to replace a datalayer rather than implementing one

[RubenVerborgh]

First of all, great job putting different developer experiences next to each other. I think we should find ways to highlight this more; there are different pieces of tooling for different environments, and it's good that people have a selection available.

There's one conceptual problem with the LDflex-based implementation, which might be a tricky one to tackle. That is, the base architecture is built around the concept of a data layer / set of data services such as getFriendNames and others.

However, the very reason we created LDflex, was to avoid such helper methods in the first place. So rather than a library for filling out a data layer, the goal is actually to get rid of the data layer. (For several simple cases at least.)

This means we have a tension here between comparison and education. One the one hand, having code of all three libraries being added to the same place, ensures an easy comparison. On the other hand, LDflex is not meant to be used in a data layer. Especially with React, its utility lies in the micro-expressions it provides.

Not sure what the best thing to do is here–or whether something should be done at all. But would be interesting to brainstorm.

[Vinnl]

However, the very reason we created LDflex, was to avoid such helper methods in the first place. So rather than a library for filling out a data layer, the goal is actually to get rid of the data layer. (For several simple cases at least.)

Just making sure I understand this: in essence, what you'd want is for the functionality of these helper methods to be part of LDflex proper, i.e. show user.friends.name rather than manually retrieving each friend individually, and then retrieving their names?

(And perhaps likewise: rather than retrieving the current user's public type index, finding a type registration for in this case schema:TextDigitalDocument, looking up that Document, and then retrieving the items in there, like I do in Notepod, you would just do user.notes?)

[RubenVerborgh]

in essence, what you'd want is for the functionality of these helper methods to be part of LDflex proper

My main point is that LDflex is normally intended to be used one level higher. So in a regular app, the code that currently calls getFriendNames would just contain user.friends.name.

The way this specific app is currently written, it could then probably use a .toArray method or so (happy to oblige), but if an app were written with LDflex directly, it could likely work its way with just user.friends.name (and benefit from the intermediate updates to the list).

(And perhaps likewise: rather than retrieving the current user's public type index, finding a type registration for in this case schema:TextDigitalDocument, looking up that Document, and then retrieving the items in there, like I do in Notepod, you would just do user.notes?)

Exactly. This would be shape work. (With the exception of .like etc., LDflex is currently only single-property-based.)

[Vinnl]

Closing due to #6.