As a developer, I can show and hide fields based on the values of other fields in an intuitive way

Apostrophe 3.x doesn’t have showFields support so far. This 2.x feature needs to be ported, or reconsidered.

The backend logic for showFields, which ensures a required field is only really required if it is visible, is already present.

We depend rather heavily on this feature across many projects, as do others. I don’t think we can leave it out in 3.x, maybe not even for alpha.

However, this is our last chance for 3.x to decide if we change from showFields to something like if (or ifFieldEquals), which some have proposed because it is more common in other systems. It also is a bit familiar to Vue developers because it works a little like v-if.

The big difference is that if is set on the field that will be shown or hidden, and makes reference to another field’s value, as opposed to the other way around.

I have a bias against making any more changes in A3 because we’re due for a release and there will be an A4 one day.

However, if it turns out that if is less complicated to implement than showFields, it would be reasonable to do it. I think this is the case.

if could look like this:

ship: { 
  type: 'boolean'
},
shippingAddress: {
  type: 'string',
  if: {
    ship: true
  }
}

Like showFields, if would need to imply that a field is not required when it is not visible. Ditto for its subfields.

There are situations where a field could become visible in two or more ways. showFields supports this, so if potentially should too. We might not have to have parity on that right away, but if we do need it, we could support a mongo-style $or query.

As for implementation, it is tempting to restore the context prop to our input components, but that would give fields more information than they need to have and could have negative impacts on reactivity in Vue.

And in fact the responsibility for showing or hiding a field is not on the field, it is on AposSchemas. I say that because it is the same logic for every field, so AposSchemas can implement it in one place without making our mixin more complicated. Also, AposSchemas is the right place to use v-if to control whether the component is present.

Since the responsibility is on AposSchemas, which can see all the fields, we could implement either showFields or if. But, it seems to me that the implementation of if requires less code.

So discussion is needed to settle on an approach here. And I think we can make that decision on the merits of showFields versus if from the website developer’s standpoint, because both are reasonable to implement. Your input is welcome.

[boutell]

In an engineering team meeting with Ben present, we agreed to:

• Implement a small subset of the mongodb syntax for the initial 3.x stable release.
• This will definitely include simple equality tests, with support for testing more than one property.
• Follow the MongoDB syntax if we add additional functionality in 3.x.
• Use Sift as our implementation, if we reach a point where the implementation effort of doing it ourselves justifies bringing in a library.

As a specification of the maximum feature set that could eventually be added, please see the sift documentation, with the exception of $where and any other sift features that involve inline functions, because those features do not transmit to the browser well.

We’re making this choice without any bias as to what might make sense in a future release.

[agilbert]

So far, Greg’s suggestion looks the most straightforward and understandable while also being flexible.

@boutell can you share examples of what you can / can’t do for logic here if we’re maintaining server and browser side compatibility?

For things you can’t do, can this be handled with clear documentation and error handling?