5f492b9b Added a members list column for each custom field filtered on
A filter told a publisher who matched but not what they said, so reading
the data they had just filtered on meant opening members one at a time.
Labels, tiers and the subscription filters already append a column for
that reason; custom fields are the case where it matters most, since a
field exists precisely because its value differs member to member. Every
custom field filtered on now brings its own column, whatever the operator,
the way Label does.
The column layer already lets a field declare a column and how to read it.
What is new is that a field whose key is a pattern stands for many columns
rather than one, so `custom_fields.:key` resolves its column per instance
from the matched key, hydrated from the fields the API loaded -- the same
hydration the filter list already does for newsletters, tiers and offers.
A name it cannot resolve is a column it does not show, which is also what
the flag being off looks like from there. Asking the API for the values
does not wait on those names, so the list does not fetch them twice, and
the fetch that names them waits for a filter rather than riding every
visit to the list.
Rendering a value as one line was the member detail screen's, and is now
the framework's user-type catalog, next to the part labels and CSV column
names it already owns. A scalar reads as it stands and a composite joins
its parts the way that type reads; the detail screen renders through the
same function, so the two cannot drift, and the catalog is total over the
field types so a new composite cannot arrive without a line to read as.
Values a publisher collected have no length a column can be sized to, so
a dynamic cell carries its full text as a native title. That is a fallback
for the edge, not a tooltip component per row across a virtualised list. ed8c9192 Added a members list column for each custom field filtered on
A filter told a publisher who matched but not what they said, so reading
the data they had just filtered on meant opening members one at a time.
Labels, tiers and the subscription filters already append a column for
that reason; custom fields are the case where it matters most, since a
field exists precisely because its value differs member to member. Every
custom field filtered on now brings its own column, whatever the operator,
the way Label does.
The column layer already lets a field declare a column and how to read it.
What is new is that a field whose key is a pattern stands for many columns
rather than one, so `custom_fields.:key` resolves its column per instance
from the matched key, hydrated from the fields the API loaded -- the same
hydration the filter list already does for newsletters, tiers and offers.
A name it cannot resolve is a column it does not show, which is also what
the flag being off looks like from there. Asking the API for the values
does not wait on those names, so the list does not fetch them twice, and
the fetch that names them waits for a filter rather than riding every
visit to the list.
Rendering a value as one line was the member detail screen's, and is now
the framework's user-type catalog, next to the part labels and CSV column
names it already owns. A scalar reads as it stands and a composite joins
its parts the way that type reads; the detail screen renders through the
same function, so the two cannot drift, and the catalog is total over the
field types so a new composite cannot arrive without a line to read as.
Values a publisher collected have no length a column can be sized to, so
a dynamic cell carries its full text as a native title. That is a fallback
for the edge, not a tooltip component per row across a virtualised list. dfb02bc6 Added a members list column for each custom field filtered on
A filter told a publisher who matched but not what they said, so reading
the data they had just filtered on meant opening members one at a time.
Labels, tiers and the subscription filters already append a column for
that reason; custom fields are the case where it matters most, since a
field exists precisely because its value differs member to member. Every
custom field filtered on now brings its own column, whatever the operator,
the way Label does.
The column layer already lets a field declare a column and how to read it.
What is new is that a field whose key is a pattern stands for many columns
rather than one, so `custom_fields.:key` resolves its column per instance
from the matched key, hydrated from the fields the API loaded -- the same
hydration the filter list already does for newsletters, tiers and offers.
A name it cannot resolve is a column it does not show, which is also what
the flag being off looks like from there. Asking the API for the values
does not wait on those names, so the list does not fetch them twice, and
the fetch that names them waits for a filter rather than riding every
visit to the list.
Rendering a value as one line was the member detail screen's, and is now
the framework's user-type catalog, next to the part labels and CSV column
names it already owns. A scalar reads as it stands and a composite joins
its parts the way that type reads; the detail screen renders through the
same function, so the two cannot drift, and the catalog is total over the
field types so a new composite cannot arrive without a line to read as.
Values a publisher collected have no length a column can be sized to, so
a dynamic cell carries its full text as a native title. That is a fallback
for the edge, not a tooltip component per row across a virtualised list. f529b004 Added a members list column for each custom field filtered on
A filter told a publisher who matched but not what they said, so reading
the data they had just filtered on meant opening members one at a time.
Labels, tiers and the subscription filters already append a column for
that reason; custom fields are the case where it matters most, since a
field exists precisely because its value differs member to member. Every
custom field filtered on now brings its own column, whatever the operator,
the way Label does.
The column layer already lets a field declare a column and how to read it.
What is new is that a field whose key is a pattern stands for many columns
rather than one, so `custom_fields.:key` resolves its column per instance
from the matched key, hydrated from the fields the API loaded -- the same
hydration the filter list already does for newsletters, tiers and offers.
A name it cannot resolve is a column it does not show, which is also what
the flag being off looks like from there. Asking the API for the values
does not wait on those names, so the list does not fetch them twice, and
the fetch that names them waits for a filter rather than riding every
visit to the list.
Rendering a value as one line was the member detail screen's, and is now
the framework's user-type catalog, next to the part labels and CSV column
names it already owns. A scalar reads as it stands and a composite joins
its parts the way that type reads; the detail screen renders through the
same function, so the two cannot drift, and the catalog is total over the
field types so a new composite cannot arrive without a line to read as.
Values a publisher collected have no length a column can be sized to, so
a dynamic cell carries its full text as a native title. That is a fallback
for the edge, not a tooltip component per row across a virtualised list. a192834f Added a members list column for each custom field filtered on
A filter told a publisher who matched but not what they said, so reading
the data they had just filtered on meant opening members one at a time.
Labels, tiers and the subscription filters already append a column for
that reason; custom fields are the case where it matters most, since a
field exists precisely because its value differs member to member. Every
custom field filtered on now brings its own column, whatever the operator,
the way Label does.
The mechanism is the one already there: a column is declared as metadata
on the field it belongs to. What is new is that a field whose key is a
pattern stands for many columns rather than one, so `custom_field.:key`
resolves its column per instance from the matched key. Naming it needs the
field's own name, which no static schema can hold, so the column layer is
now handed the fields the API loaded -- the same hydration the filter list
already does for newsletters, tiers and offers. No resolved name means no
column, which is also what the flag being off looks like from there, and
without a column `custom_fields` is never asked of the API.
Rendering a value as one line was the member detail screen's, and is now
the framework's user-type catalog, next to the part labels and CSV column
names it already owns. A scalar reads as it stands and a composite joins
its parts the way that type reads; the detail screen renders through the
same function, so the two cannot drift.
Values a publisher collected have no length a column can be sized to, so
a dynamic cell carries its full text as a native title. That is a fallback
for the edge, not a tooltip component per row across a virtualised list.