Attributes typed _componentWithSelectableType tell authors nothing, and default to number when the surrounding type is not numeric

[dqnykamp]

Problem

Several attributes are declared createComponentOfType: "_componentWithSelectableType", and the reference docs print that name verbatim as the attribute's type. _componentWithSelectableType is an internal abstract component; it tells an author nothing about what to write.

It affects 15 attributes across 9 components:

Component	Attributes
<sequence>, <selectFromSequence>, <repeatForSequence>, <animateFromSequence>	from, to
<slider>	bindValueTo, initialValue
<substitute>	match, replacement
<updateValue>	newValue
<indexOf>, <searchSorted>	target

Why it is more than a wording problem

The value's type is resolved at sugar time by ComponentWithSelectableType: its own type attribute, else the parent's type attribute, else the default number. So when the author does not state a type, the value is parsed as a number — even when everything around it is text.

That silently produces wrong answers rather than an error:

<textList name="words">apple banana fig pear</textList>

<searchSorted type="text" target="cherry">$words</searchSorted>   <!-- 3, correct -->
<searchSorted target="cherry">$words</searchSorted>               <!-- 1, silently wrong -->

<indexOf type="text" target="fig">$words</indexOf>                <!-- 3, correct -->
<indexOf target="fig">$words</indexOf>                            <!-- 0 -->

The last line reports indexOf did not find NaN among its values — the target was parsed as a number, became NaN, and matched nothing. The NaN in that message is the only visible trace of the cause. The <searchSorted> line gives no diagnostic at all: it returns 1, a perfectly plausible position.

The type an author needs is not always the type attribute

For the index operators the target has to match the type of the list entries, which is usually decided by the children — a referenced <textList>, say — and not by a type attribute at all. type exists to say how bare string children should be read; it happens to double as the target's type because ComponentWithSelectableType falls back to the parent's type. Those two jobs coincide often enough to be confusing and diverge often enough to be wrong.

There is no way to look up the resolved type

Of the nine components, only <substitute> exposes a public type property. The other eight have a type attribute but no readable property, so an author cannot inspect what was chosen:

Component	type attribute	type property
<substitute>	yes	yes
<sequence>, <selectFromSequence>, <repeatForSequence>, <animateFromSequence>, <slider>, <updateValue>, <indexOf>, <searchSorted>	yes	no

Most of these declare type with createPrimitiveOfType: "string" and no public: true, which is why it never becomes a property.

Possible directions

Not a proposal — the right fix probably combines several of these:

1. Render a meaningful label in the docs. Map _componentWithSelectableType to something like number, math, text, or boolean — follows this component's type instead of leaking the internal name. Cheapest fix, and it addresses the reported symptom.

2. Make type readable. Mark the type state variable public on the components that have one, so $seq.type works and matches <substitute>. Note the docs would then also need the attribute to explain what it governs.

3. Infer the type from the entries where the entries define it. For the index operators, deriving the target's type from the children would make <indexOf target="fig">$words</indexOf> simply work. This is the part that goes beyond wording.

4. Diagnose the mismatch. Where inference is not wanted, warn when a target parses to NaN against a list that is not numeric — the case above is currently silent for <searchSorted>.

5. Declare the valid values of type, so autocomplete offers them. Five components accept a type but declare no values for it, so the editor can suggest nothing and the docs show no value table. The set they accept is already known — the shared sugar warns (doenet-w0014) on anything outside math, text, number, boolean — it is simply not declared.

   type declares its values	type declares nothing
   <sequence>, <selectFromSequence>, <repeatForSequence>, <animateFromSequence> (number, math, letters); <slider> (number, text); <substitute> (math, text); <updateValue> (math, number, boolean, text)	<sort>, <shuffle>, <sortIndices>, <indexOf>, <searchSorted>

   The ones that declare values use createComponentOfType with validValues; the ones that do not use a bare createPrimitiveOfType: "string". packages/lsp-tools/src/auto-completer/index.ts reads a.values for attribute-value completion, so declaring them is what makes the editor offer them. This is the smallest and most independent item here — it needs no decision about how the selectable type is resolved.

   Done for the five in Add list operators: cumulative scans and list indices #1824 (<sort>, <shuffle>, <sortIndices>, <indexOf>, <searchSorted>, plus <argMin> and <argMax>), which all now declare number, math, text and boolean. <slider>, <substitute>, <updateValue> and the sequence family already declared theirs, so this direction is complete unless a component is found that still does not.

6. Give the schema a way to express it. An attribute whose type is "the resolved type of this component" is a real concept the schema cannot currently state; several of the above become easier if it can.

Scope

Nine components, the docs type-rendering pipeline, and possibly schema generation. Deliberately not addressed in #1824, which introduced <indexOf> and <searchSorted>: their target matches what <sequence> and the others already do, and changing that convention belongs in one change across all of them rather than for two new components alone.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01JMbAScbaa3RtikSh9C3qam

[dqnykamp]

Four corrections after working through #1827–#1830, all measured on that stack rather than reasoned about.

1. The count is low, and it was low before this stack

"15 attributes across 9 components" is exactly the number of attributes typed _componentWithSelectableType. But the same leak happens under two more internal names, which the table does not list:

internal name	on main today
_componentWithSelectableType	15
_componentListWithSelectableType	4 — exclude on <sequence>, <selectFromSequence>, <repeatForSequence>, <animateFromSequence>
_componentListOfListsWithSelectableType	1 — excludeCombinations on <selectFromSequence>

So it is 20 attributes across 9 components on main, not 15, and any fix under direction 1 has to map three names rather than one.

After #1827–#1829 it is 22 across 11: target on <indexOf>/<searchSorted> moves from the scalar name to the list one (it now takes a list of targets), and categories on the new <tally> and <barChart> is a _componentListWithSelectableType too. The leak grows with each new component that wants an author-typed value, which is the argument for fixing the rendering rather than the components.

2. The type-property table changes for two rows

#1827 gives <indexOf> and <searchSorted> a real type state variable. It had to: target is a _componentListWithSelectableType, whose own type resolves through parentStateVariable, so without one a text target was converted numerically and compared as NaN.

It is not public, so there is still no $op.type property — but for these two, direction 2 is now a one-word change (public: true) rather than a new state variable.

3. The worked example's diagnostic claim is wrong

The issue says the last line "reports indexOf did not find `NaN` among its values". No such message exists — nothing like it has ever been in diagnostics.ftl, and #1824 deliberately does not report an absent target, on the grounds that answering 0 is what <indexOf> is for.

Measured on the #1827 branch, against <textList name="w">apple banana fig pear</textList>:

markup	result	diagnostics
<searchSorted type="text" target="cherry">$w</searchSorted>	3	none
<searchSorted target="cherry">$w</searchSorted>	1, silently wrong	none
<indexOf type="text" target="fig">$w</indexOf>	3	none
<indexOf target="fig">$w</indexOf>	0	none

Both lines are silent. There is no visible trace of the cause at all, which makes direction 4 more valuable than the issue currently suggests, not less: the sentence about NaN being "the only visible trace" describes a message that would at least have pointed at the problem.

4. Vectorizing makes the failure mode worse

With <textList name="want">fig pear apple</textList>:

<indexOf target="$want">$w</indexOf>              <!-- 0, 0, 0 — silently wrong -->
<indexOf type="text" target="$want">$w</indexOf>  <!-- 3, 4, 1 — correct -->

Still no diagnostic. Where a missing type used to cost one wrong number, it now costs N of them, and the wrong answer is a plausible-looking list rather than a single suspicious zero.

Direction 5 is unaffected — still complete for these components.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_016YdEWccVoUPCJoDYxKmHRo

[dqnykamp]

Two more instances, and a remedy that has now been built

#1829 hit this twice in new components, and fixing it there turned up both a working shape for direction 3 and a trap in implementing it. Recording that here, since the general fix still has to be made.

The instances

<barChart categories> was declared _componentListWithSelectableType. Written without a type, categories="North South East" labeled every bar NaN. The fix was not to resolve the type better but to notice the attribute never needed one: a category names a bar and never positions it, so categories="1 5 6" places bars at 1, 2, 3 either way. It is a textList now and <barChart> has no type attribute at all.

<tally categories> could not take that route — a category there is compared against the values, so it genuinely has a type. Written without a type, categories="apple fig" became two NaN categories, matched nothing, and then tripped the repeated-category warning, because against a non-numeric list NaN compares as text and "NaN" == "NaN". The author was told they had named the same category twice, naming a value they never wrote.

So the count in the table above is now 16 attributes across 10 components; <tally>'s categories is the new one, and <barChart> is a candidate that was removed rather than repaired.

What direction 3 looks like when built

<tally> now defaults its categories to text and rereads a textual category as a number at the point it is compared, when the values are numeric. Text is the reading that survives comparison against any type — a word stays a word, and categories="1/2 1" still counts halves. Only text is reread: a category that arrived as a component already is the value it names, and rereading its displayed form would break it, since a third displays as 0.333 and no third equals that.

That last point is worth generalizing. An earlier attempt made the attribute a plain textList, which reads well for labels and silently returns wrong answers for anything compared numerically. Whatever the general fix is, it must not launder a value through its own display.

The trap: the type reaches such an attribute by two independent routes

They must agree, and nothing makes them:

1. The sugar that wraps the bare strings reads componentAttributes.type and then parentAttributes.type — raw attributes, at expansion time.
2. The type state variable on the created component reads dependencyType: "doenetAttribute" and then parentStateVariable: "type" — state variables, later.

Setting one and not the other does not fail; it produces values built as one type and read back as another. We hit that twice while building this: strings wrapped as text and then reported as numbers gave NaN categories, and strings wrapped as text and reported as booleans gave "false" read back as true, since a non-empty string is truthy. Both were silent. A general fix needs to reconcile these two routes once, in ComponentWithSelectableType, rather than leaving each component to line them up by hand — which is all <tally> does today.

A prerequisite that has been fixed

copyComponentAttributesForCreatedComponent matched attribute names case-sensitively, while every other reading of an attribute in DoenetML is case-insensitive, so <tally TYPE="boolean"> left type uncopied and produced the truthy-string failure above. Fixed in #1829 (convertNormalizedDast.ts); <mathInput>, <matrixInput> and <fractionInput> copy into prefill through the same path and gain the same tolerance. Any component taking this route needed that first.

Direction 7: one type value resolves three different ways in one component

Distinct from everything above, and family-wide. Attribute names are matched case-insensitively; attribute values are not, and the three places that read this one disagree about what to do with a value they reject.

<tally type="Text" categories="apple fig">$someTextList</tally> produces NaN, NaN and counts 0, 0, reporting all of:

info:    Invalid value `Text` for attribute `type`, using value `text`
warning: Invalid type Text for tally component. Must be one of math, text, number, or boolean. Defaulting to math.
warning: Invalid type Text, setting type to number.
warning: `categories` names the same category more than once.
info:    Some values matched none of the declared categories, so they were not counted.

Three readings of one written value — text from the component's own state variable, which matches validValues case-insensitively; math from the children sugar; number from the attribute's selectable type — and a repeated-category warning for a duplicate the author did not write. It is loud rather than silent, which is the one mercy, but no author can act on five messages that contradict each other.

It is not confined to the counting operators. <sort type="TEXT"> warns "Defaulting to math" and then sorts correctly, because its children were already text and the wrong default never mattered; <indexOf type="Text" target="fig"> reports 0 with two contradictory warnings. Verified by running each of these.

The fix is to lower-case the value in one place rather than four — ComponentWithSelectableType, ComponentListWithSelectableType, returnBreakStringsIntoTypeSugarInstruction and returnListTypeAttribute all decide independently today. Deliberately left out of #1829: it changes already-merged components and is not about that PR's chart.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_016YdEWccVoUPCJoDYxKmHRo

[dqnykamp]

Two more concrete symptoms, both found while building #1847 and both left alone there because they live in _componentWithSelectableType rather than in that PR's diff.

An invalid type now gets two opposite remedies in one component

#1847 changes the children sugar so that a type outside the four is reported and dropped, leaving the children read as though none had been written. The attribute path still replaces it with number (ComponentWithSelectableType.js, the else if that raises doenet-w0016). So one component now answers the same mistake two different ways:

<indexOf type="txt" target="b">a b c</indexOf>

reports both "Invalid type txt … Ignoring it and reading the values as though no type had been given" and "Invalid type txt, setting type to number". An author reading the panel is told the value was ignored and told what it was changed to.

A written type can be worse than no type at all

<tally categories="apple fig">apple fig apple</tally>            <!-- 2, 1 -->
<tally type="txt" categories="apple fig">apple fig apple</tally> <!-- 0, 0 -->

The second gives categories NaN, NaN, counts 0, 0, and a "names the same category more than once" warning for a duplicate nobody wrote — one NaN reads like another. Verified identical before and after #1847; that PR does not touch it.

The mechanism is mine, from #1829, and worth recording plainly. <tally>'s categories is declared:

attributesForCreatedComponent: { type: "text" },        // the default when nothing is written
copyComponentAttributesForCreatedComponent: ["type"],   // a written type wins

The copy takes the unflattened attribute, before expansion, so it is the raw txt that lands on the created component — which then applies its own fallback and reaches number. Validating at the source does not help: validatePrimitives runs during expandAttribute, after the copy has already read the raw value.

That is the concrete reason this could not be fixed alongside #1847. Any real repair changes _componentWithSelectableType or the copy plumbing, both shared with <sequence>, <selectFromSequence>, <repeatForSequence>, <animateFromSequence>, <slider>, <substitute> and <updateValue> — most of them released.

The part that is not accidental

Worth separating, since it constrains any fix: the attribute genuinely cannot infer its type from the values the way the children now do. categories and target are expanded before the children's values exist — when the children are a reference, their types are still unknown — so joint inference is not available at that point. <tally> reconciles later instead, at comparison time, by rereading a textual category against numeric values. Whatever replaces the current fallback has to respect that ordering; matching the children's rule exactly is not on the table.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_016YdEWccVoUPCJoDYxKmHRo