Perspective Data Properties in view.json

Ignition
1

I am version controlling a perspective project that pulls in a ton of variant data, and we always all complain about the data that gets tracked in the repo causing giant unnecessary changes whenever we do merge requests. All because someone had the view open in their designer, it changed the data on it, and they hit save.

I am trying to understand how I can keep this contextual data out of the view.json in the repository. I thought that any custom properties with bindings don’t actually store the data on the property, but maybe I am missing something there.

i.e. I see both things in the view.json

{
  "custom": {
    "myBigProperty": ["My", "Giant", "List"]
  },
  "params": {},
  "propConfig": {
    "custom.myBigProperty": {
      "binding": "All of the stuff to say this is a named query with a script transform",
      "persistent": true
    }
  },
  "... Other stuff ..."
}

How do I make sure that custom.myBigProperty doesn’t show up? (In reality its an array of 2k complicated objects, and way more annoying than a list of 3 strings)

EDIT: I have a feeling someone is going to say to mark it as not persistent, but then I thought my binding disappeared too?

2

Mark it not persistent :slight_smile:
In fact, any property with a binding is automatically not persistent, unless you go in and change it to be persistent. "Persistent" refers only to the serialization of values, not to the retention of the binding.

1 Like
3

I think potentially there is a bug here, in 8.1.17 (I am also pretty sure this has been happening for a while before 8.1.17, because we have views with this written months ago) I just created a random expression binding on a random page to just return false and it was persistent by default. I am not sure we have ever marked something as persistent or not, but 99% of the bindings in our app are so there may be a bug here with the default

EDIT: Gif evidence (Annoying how slow it makes it, but you get the point)
Screen Recording 2022-05-25 at 2.08.40 PM

4

Hmm, that’s not what I’m seeing:
Kapture 2022-05-25 at 15.01.39

I wonder what the discrepancy is.

EDIT: It looks like view custom parameters are still automatically persistent?

5

That is what I was about to say, but you beat me to it.. cde50dc23177881f

Looks like the behavior is different on view custom properties versus container and component props.

6

So, I did some spelunking (spurred on by the fact these changes had my name on them :grimacing:) and it looks like this is intentional. Early on in Perspective’s lifecycle, lots of people were confused because if you have a non persistent property, you won’t see it until a value has been delivered the first time the binding evaluates. This normally isn’t an issue, because most of your bindings will be on regular component props, but could be confusing for custom properties you “know” will be there, so we made the decision to default view params and view custom properties to persistent.

7

That would be it, 99% of our data bindings are on the view so that all the components can bind up to the view and not worry about reference paths for sibling data.

8

I guess I would say that's not really the case for data heavy pages. Typically on pages that need a ton of data it makes sense to put it on the view itself so that everything can bind upwards to it. That way if you move things around in containers you don't have to rebuild all of your bindings. Typically you want to make the data as accessible as possible to the components on the view that might be binding to it.

9

At least there’s a checkbox? #silverlining :grinning:

10

Lol true

Would be good to make that some level of user configurable thing. It would be nice for the power-users that are comfortable with dealing with data visibility and all of that stuff to not have to worry about making sure that box is unchecked for everything (extra unnecessary checks tbh)

Something like what is mentioned on this feature ticket Paul mentioned: [IGN-572]Flex as default view type - #16 by PGriffith