Ah, so I had discounted that as an option. requiring a separate read because that basically means that the pattern would necessitate multiple queries. You’d be opting into worse performance with that pattern, and would still have both records with the fields hidden and records without in the same liveview, so the mistakes that can be made are just moved, not actually eliminated.
There is a field called original_value that we use in certain circumstances to track the hidden value (this is required to write-back embedded resources when the user can’t see all the fields). We could populate that when hide_private? is used, so that would have the effect of making one additional step required to use a private field in your liveview (prompting the developer to reconsider), and would also prevent the need for making multiple queries to prevent that class of mistakes.
The reason hide_private? makes sense to me is:
- It’s backwards compatible with existing usage.
- There should never be a private attribute with a field policy that can pass. That means it’s public (to at least someone).
Thoughts?
EDIT: so like if you just did record.private_field you’d see %Ash.ForbiddenField{}, but if it’s an “internal usage” you could say record.private_field.original_value (only for private fields)
