Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

tylernathanreed's avatar

Nova Field Management

I'm working on a Nova application that already has over 1,000 fields (based on the number of columns we're mapping, the final count will end up being north of 30,000 across 400+ resources).

I'm fine with defining each field individually, but our code base is slowly developing new problems. I'd like to create some sort of field management system that helps minimize the following problems:

1) We need a "Data Dictionary" of sorts.

It's not easy to answer the question, "What are the names of all of my fields, and under what context (i.e. "Create User", "Book Flight", etc.) do they appear?

We'd want this information to be accessible to both the development team and many users on the site, so it makes sense that we'd like this to appear in the UI somewhere.

Additional problems come into play with calculated fields, which make use of closures. We'd need a way to explain at the field level what the calculation is doing, as just saying "ComputedAttribute" won't be sufficient for us.

2) We need to be able to share field definitions across multiple resources and/or actions.

A common example that we have is a calculated field on a resource that appears on many "child" resources (the calculation is the same, the field is just important enough to the business to show in multiple places).

A much more common example is Lenses, which reuse several fields from the Index page. I know that we could create static methods on the resource to handle this, but that doesn't fit a design pattern that also solves for #1.

3) We want our field definitions in the code, not in the database.

We considered creating a "Field" resource, but we don't want our backend fields to be data driven. Our reason for this is if someone removes a field, it could break the code; or if they added a field, it would have no use.

I'm not saying that we can't have our field dictionary in the database (and making it a read-only table generated by an artisan command or something). We just don't want the fields in the database to drive functionality in the code.

--

Are these problems that you guys have faced? If so, how did you solve them?

0 likes
0 replies

Please or to participate in this conversation.