Xplat docs xplat json snippet support and refactor and automated docs testing - #497
Open
gmurray81 wants to merge 128 commits into
Open
Xplat docs xplat json snippet support and refactor and automated docs testing#497gmurray81 wants to merge 128 commits into
gmurray81 wants to merge 128 commits into
Conversation
…ration A ```json-snippet block holds one sample as JSON and becomes this platform's markup as the page is generated, replacing the four or five hand written blocks a topic otherwise carries for the same sample. Purely additive: every other block is left exactly as it was, so a topic can hold both forms and a platform specific snippet with no JSON equivalent keeps working. Verified by generating every platform against the unmodified repo — the platforms whose blocks were not collapsed come out byte identical. The emitter is the locally built renderer, loaded through a CommonJS bundle and only when a page actually contains a json-snippet, so pages without one are untouched. A failure fails the build rather than publishing a page with a hole where a sample should be. Collapses one section of bullet-graph as the first case: three PlatformBlocks and 76 lines become one 22 line block, and Angular, React and Web Components each come out matching what was there before. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Collapsing a per-platform snippet group into one JSON definition forces a single
answer. Where the platforms already agree that is mechanical; where they differ,
the difference is almost certainly a mistake that has to be fixed first, because
collapsing would otherwise silently pick a winner and change what some platform's
page has always shown.
Compares content rather than dialect: element names, attribute names, quoting and
layout all differ legitimately between platforms, so all of these read the same
and report nothing —
<igx-bullet-graph minimumValue="5"> <IgrBulletGraph minimumValue={5}>
<igc-bullet-graph minimum-value="5"> <IgbBulletGraph MinimumValue="5">
It reports when one of them says 55 and the others say 5.
Two things had to be got right before the output meant anything. Only elements
carrying a platform prefix count, so a topic wrapping a sample in a <div> and
XAML's property elements do not shift everything after them. And a group ends
when a platform repeats, not only when prose intervenes: not every sample carries
a block for every platform, and without that a group missing one swallows the
next sample's first block. That alone took the false "different component"
reports from 534 to 86.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…riance
The generator now states the style a documentation snippet is written in — one
line of attributes, no invented element names, and no dimensions on the XAML
platforms — so a sample only says what is particular to it.
The divergence check now sets aside the differences that are expected rather than
wrong:
* dimensions, which are presentation and now handled by a style option
* property renames, taken from the vendored apiMap rather than a hand kept
list, so ItemsSource and dataSource are recognised as one property
* binding syntax, so {Binding SalesData}, this.state.salesData and SalesData
are recognised as naming the same thing
* an absence explained by binding, where the platforms that do write the
property are binding and another binds in code instead
* colours and numbers, which the topics pick freely as illustration
What is left is content that says something: a field, a data type, an icon, a
class. 747 differences over 246 groups, down from 2008 over 455 when everything
was reported.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Lining elements up by position made one legitimate difference throw off every
comparison after it. A platform carries an element the others do not — XAML
declares the axes a CategoryChart infers, Angular groups columns in a layout —
and everything past that point was reported as different when only one thing was.
That was what "is a different component" and a bare "element count" were: 169
reports that said nothing usable.
Comparing per component instead says what is actually wrong, and where:
how many column: Angular: 0, Blazor: 6, WebComponents: 6, React: 9
column 2 datatype: Blazor: string, React: number
Also splits a platform showing none of a component from the platforms that show
it and disagree about how many. The first is a topic illustrating a feature with
a smaller piece of the sample, which is deliberate; the second is a real
disagreement.
Two further corrections to what the apiMap was doing. A rename was applied
globally, so one type renaming IconName to `name` turned every name attribute in
the docs into an icon — a rename is now ignored when the platform's name is
itself a canonical name elsewhere, or maps to more than one. And the plumbing
attributes are recognised on the name as written, before a rename can disguise
them. Razor's @salesdata now reads as the binding it is.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The product names a web-only description WebGridDescription, WebColumnDescription, WebDatePickerDescription, while a component shared with the XAML platforms has no such prefix — DataGridDescription, BulletGraphDescription. The presence of a Web<Name>Description in the apiMap is therefore the product's own statement that a component is web only, and those are out of scope: collapsing a group into one definition pays where the definition serves every platform, and a web-only component has no XAML counterpart to reconcile against. That takes the field from 710 groups to 153, and the topics to reconcile from 116 to 49. Renames are also looked up per component now rather than globally, since a rename belongs to a type: ItemsSource is written dataSource on some types while DataSource is a property in its own right on others. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The apiMap cannot answer what a XAML attribute is called canonically: its files are generated per transpile target and XAML is the canonical side, so there is nothing there to map from. The description metadata records every platform's name for a property in one entry, and is the only thing that knows dataSource and ItemsSource are one property. The check now asks it, through the snippet emitter it already depends on. A data source is a special case worth stating: the description carries both DataSource and DataSourceRef — the value and a reference to a named one — and a topic writes whichever suits it, XAML almost always the reference and a sample configuring an inline source the value. They are one concept for comparing, so the Ref is folded in. Two things this needed. The metadata is keyed by the description's own casing while a doc tag arrives lowercased, and a web-only description is also reachable by its bare name since <igc-grid> canonicalises to "grid" rather than "webgrid". And a PlatformBlock gates on groups as well as platforms — "Xaml" is not a platform the metadata knows — so the block's audience is resolved to a member of its group. With that, the 25 reports of datagrid's data source splitting into two properties become 14 real ones. The apiMap is still what says a description is Web-prefixed, which is what scopes the check. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… peers Decides whether a group can become a json-snippet referencing its sample, by reading each platform's block back into the properties it states, resolving those to their description names, and comparing each with the sample's value. A group that is a subset of its sample can be collapsed mechanically: the sample is provably the source, so the block becomes a reference plus the properties it illustrates, and the topic stops being able to drift from what it shows. A group that is not a subset needs a person, and the tool prints every platform's version so the call is made from what the topic actually says. Three things had to be right before the answer meant anything. A sample writes its properties camel cased while a description names them Pascal cased, so lookups go through a lower cased index. Web Components writes them spinal cased, so the dashes come out before asking the metadata. And a sample sitting between two blocks starts a new section — the topics write some platforms, then the sample, then the rest — which without handling pairs a group with the wrong sample and makes every property look like a disagreement. Current reading: 4 collapsible, 56 needing a decision, 138 with no peered sample. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A platform stating the sample's own values settles that the sample is the scenario the section is about. The others have drifted from it, so the group collapses to the sample and they come back into line — bullet-graph's measures section has React and Web Components on the sample's numbers while Blazor is on an entirely different set and Xaml on a third. Pairing decides which sample a group belongs to, and direction turned out to be the wrong axis: a topic's opening sample sits above its first snippet while a section further down writes the snippets and shows the sample under them. Both orders occur, so pairing uses the enclosing heading section instead — a section is about one thing, including its sample. A section with more than one sample is left unpaired rather than guessed at. --plan prints what each collapse changes, per platform, so the editorial consequence is visible before anything is rewritten. 13 groups collapse on this rule, 14 have no platform agreeing with their sample and need a decision, 171 have no sample in their section. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Splits the unpaired count into its causes: no sample in the section, more than one, or a sample whose file is not in the examples checkout. The last is the one that matters — it is not a property of the docs but of which branch of the examples repo is being read, and the counts move with it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… say Three pairing rules were wrong before this one. Nearest by distance pairs a group with the previous section's sample. Looking only backwards, or only forwards, each mispairs about half, because a topic's opening sample sits above its first snippet while a section further down shows the sample under them. Sectioning by heading rejects pairings that are plainly related: of the blocks with a sample within a screen's distance, more than half have a heading in between. What actually separates one sample from another is another snippet group, so a group owns everything between the group before it and the group after. That took paired groups from 27 to 62. Where position cannot decide, content can: a sample of the same component that covers the properties a platform states is likely the one being illustrated. Matched on which properties are set rather than their values, since values are exactly what has drifted — a topic states value=70 beside a sample running value=80, so matching on values finds nothing. Also adds the fallback to igniteui-wc-examples: a sample missing from the examples repo but present there is not missing, it is not yet back ported. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Many snippets appear to be written from scratch rather than narrowed from a sample: for one gauge topic, twenty samples of that component existed and none set even the same properties, let alone the same values. So requiring agreement finds nothing, and the useful question is which sample best covers what the snippet sets, preferring one the topic already shows. That takes content matches from 3 to 26 and paired groups to 88 of 198. Reported separately from positional pairing because the quality differs. It gets the obvious ones right — geo-map-binding-data-csv to the csv sample — and pairs some confidently wrong: a topic about binding multiple sources matches the csv sample, because with values excluded the two set the same properties. A wrong pairing is worse than none when the purpose is to re-anchor a snippet to the sample's values, so these want confirming rather than applying. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…t the schema The topic carried five hand-written blocks per section saying the same thing in five spellings, and they had drifted apart. Nine sections become nine JSON definitions, 1374 lines become 418, and en and jp are collapsed together. Every XAML block in the topic turned out to have been written from the hero animation sample rather than each section's own, in all six sections that have one. The XAML in these topics has never been compiled or run, so where it disagreed with the web platforms the web platforms won. SNIPPET-COLLAPSE-DECISIONS.md records that and the three sections that did not collapse trivially. Generation now emits the JSON schema and checks every json-snippet against the description it names before writing any output, reporting all the problems at once rather than failing on the first property the renderer happens to reach. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The topics write isScaleInverted={false}, not "false". Matches how React's numbers were
already handled.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…hows chart-annotations displays three data-chart samples while every one of its snippets is a CategoryChart, and the CategoryChart annotation samples it was written from are never mentioned on the page. Pairing on the embedded <Sample> reported it as needing samples back-ported from another repo when the JSON was already in this one. Indexes every sample by the property names it sets, compared without each platform's spelling, and ranks by how much of the snippet a sample covers. Across the 125 DV snippet groups, 42 have a sample covering at least 80% of what they set, and 29 of those name a sample the page never shows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…n from Every snippet on the page is a CategoryChart while the three samples it embeds are DataCharts. The CategoryChart annotation samples the snippets came from are never mentioned on the page, which is why this topic first looked like it needed samples back-ported from another repo. The XAML binding to TemperatureAnnotatedData gives it away — that is annotations-custom's own dataSourceRef. Two of the three callout member paths named fields that do not exist in the data. Taken from the running sample. The XAML callout snippet sat after the Timeline Styling section rather than with the callout markup it duplicates; folded in. en and jp collapsed together. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The emitter was dropping enum collections on every platform but XAML, so the property the Callout Layer section describes appeared in no snippet. Now that it emits, it is in the JSON. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…y tool radial-gauge goes from 1497 lines to 467, ten sections becoming ten JSON definitions in en and jp together. Same cause as bullet-graph: every XAML block carried the hero animation sample's values rather than its own section's. The candidate matcher now prefers a sample of the same component. The gauges share most of their property names, so a radial gauge section about ranges matched the linear gauge's and the bullet graph's ranges samples at 100% on properties alone; only the element being shown says which component the reader is looking at. mirror-collapse-to-jp.mjs replaces the ad hoc scripts. It walks both copies as ordered sequences of snippet positions rather than matching fences to groups, which misaligns as soon as one group in a topic is left hand written — as Dependencies is here — and it refuses to write at all when the counts disagree, since two copies that have drifted need a person. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1448 lines to 413, nine sections in en and jp together. Six matched their own sample outright; the three that did not are recorded in SNIPPET-COLLAPSE-DECISIONS.md. Every XAML block again carried the hero sample's values rather than its section's — NeedleShape="Needle" where every web platform says Custom, #79797a where they say DodgerBlue. Third topic in a row, and the same cause each time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… need code Both topics carried a bare map plus, for every platform, a code block constructing the imagery and assigning it to backgroundContent. backgroundContent is an ordinary described property whose value is another description, so each becomes one JSON with the imagery nested, and the generated markup needs no code at all. check-snippet-code-channels.mjs is what makes that claim checkable rather than hopeful. Some properties cannot be written as an attribute on some platforms — a data source on Web Components is assigned in script — and a topic showing only markup would then tell the reader to bind a source without saying where it comes from. The renderer already decides what it cannot write as an attribute, so the check asks it: 2 of 32 collapsed snippets set something in code, both Web Components in chart-annotations, and both still have a companion code block beside them. The mirror tool now aligns on heading sections rather than snippet positions, since a collapse often replaces several groups with one JSON, which the positional match refused outright. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…dropped something Some properties cannot be written as an attribute on some platforms — a data source or a tooltip template on Web Components is assigned in script — and a topic showing only the markup leaves that platform's reader with a series bound to nothing. The emitter is what decided to leave it out, so it is what says a code block is needed: if anything was dropped it appears, and if nothing was, nothing appears. Angular binds in the template and gets no block; Web Components gets its two assignments. What that block shows is the assignments alone, which is what 149 of the 192 code blocks in the hand written topics show. The 36 that also show how the reference was obtained and the 27 that declare a field are the introductory pages: code="allCode" gets that fuller form, and code="none" turns it off for a topic that would rather write its own. A ref= fence can still name a channel explicitly. geo-map-type-scatter-symbol-series is the first topic collapsed this way: eight hand written blocks become one definition, and the generated shape matches the original per platform — one block for Blazor and XAML, two for Web Components. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bubble series, polygon series, polyline series and the shapefile binding page: 37 hand written blocks become four definitions, en and jp together. The shape data sources nest declaratively, so the shapefile and database URLs are in the markup where the topics used to assign them in code. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ode blocks
Creating Series and Map Background collapse; the shapefile loading and per-record processing
sections stay, since they are handlers rather than configuration.
The collapse found a typo the hand written markup had carried: Web Components wrote
shape-memberPath where the attribute is shape-member-path, so that property had been doing
nothing.
Two faults in the mirror, both found by the Map Background section:
- it grouped only markup fences, so a section whose blocks are all ts was not seen and the
snippet was inserted after the blocks it should have replaced, leaving the page with
both. Seven earlier mirrors had silently left the Japanese copy holding code blocks the
English one had dropped; those are re-mirrored here from the pre-collapse originals.
- replacing every group in a collapsed section would have taken the hand written Web
Components block chart-annotations deliberately keeps. A block the English copy still has
is now left alone, recognised by its body, since only the prose is translated.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Data aggregations matched its sample outright. Its initialGroups and initialSummaries now read Country and Sum(Sales) as Sales, from the sample, where the page wrote them lowercase; the sample is what runs against the data. The overlay text section had Web Components and XAML declaring a DataAnnotationSliceLayer and Blazor building the same thing in a method with three styling properties the other two did not show. Collapsed to the union, so every platform now shows the border thickness, border radius and padding that only Blazor had. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… was missing The XAML block under Chart Marker Size was the wrong snippet: the section is about MarkerSize on a ScatterLineSeries and XAML showed a LineSeries chart with callout, final value and crosshair layers and no marker size at all. Collapsed to what the three web platforms agree on and the prose describes, so XAML now demonstrates the property the section is named after. The web blocks referred to axes they never declared; the definition declares them. The reset example uses null, which is how the description API spells NaN. The Japanese copy was missing the Chart Checkmark Marker Type section entirely, which is why the mirror refused to run on this topic. Translated and added, so the two copies have the same structure again. The translation is mine and has not been through localisation review. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The window coordinate section offers two forms of the same thing — a windowRect, or the three positional properties — so it becomes two snippets with the page's own "or" between them, which is what it already said. Geographic Coordinates is left alone: it calls zoomToGeographic, and a description says what a thing is rather than what to call on it. The library has MapNavigationOnViewInit holding exactly that call, so this wants the handler channel rather than hand written code. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…t out The Geographic Coordinates section showed a zoomToGeographic call, and the library already holds exactly that call as MapNavigationOnViewInit. The snippet names the handler and the build emits its body, per platform: a Rect literal on Blazor, a constructor on XAML, an object on the web. The new missing library item check earned itself immediately — it caught a dangling tooltipTemplateRef the multiple shapes collapse had introduced, pointing at that page's own ng-template rather than anything in the library, which would have emitted a reference to nothing. The mirror now refreshes a snippet that is already collapsed on both sides but has since changed in English, which is how that stale reference would otherwise have survived in the Japanese copy. Two snippets under one heading still cannot be placed automatically, but they no longer block refreshing a section that has nothing left to place. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The CSV binding, JSON points binding and high density series pages each build their series in
a routine the library already holds — MapBindingDataCsvOnViewInit and the other two — so the
topics name the handler and the build writes it out per platform. 24 hand written blocks
become three definitions and three handler references.
Two faults in the mirror, both surfaced by these being the first topics with two snippets
under one heading:
- it placed one snippet per section, so the second was silently dropped. A section is now
replaced whole, with its snippets in the order English has them, which also removes the
need to work out which snippet replaced which group.
- its fence pattern required a body, and a ref fence has none, so those were invisible to
it entirely.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…e with it A few sections show two components side by side because the point is the comparison — an ordinal axis on a FinancialChart and on a DataChart, markers off on a CategoryChart and on a DataChart's LineSeries — and neither is a child of the other. A snippet body that is a JSON array emits them in order, one blank line between, which is what the hand written block did. This is the case that justified the form; nothing else in the set needed it. The two guideline sections showed property assignments on a chart the reader already has and now show the properties on the components, which is how the rest of the documentation states them and what the comments in the original were already describing. It does change what those sections demonstrate, and SNIPPET-COLLAPSE-DECISIONS.md says so, along with the two faults it corrects: this.Chart.Resolution with a capital R on the platforms where that is not the property, and the Blazor block setting it twice. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ling The two guideline sections show a property being set on a chart the reader already has. That is the lesson, so they are emitted as code rather than markup: asking for a component's code channel now forces code behind, which is what that work was for. All five platforms show the assignment again rather than a declaration. Also stops two styling differences that the style options exist precisely to prevent: selfCloseEmptyElements was set for React alone, though the topics close an empty element on its own tag in Blazor and XAML as well. An enum qualification option was added and then removed: the docs write MarkerType.Circle 315 times and the bare form never, so the emitter was already right and the one unqualified block in chart-markers was an error. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Spreadsheet has no description type — not among the 1190 the schema is generated from, and there are no spreadsheet sample JSONs in the examples repository at all. The renderer has nothing to emit from, so this is a limit of what is described rather than a view about the pages, and they become collapsible the day the component is described. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ge is about
Two more from the audit, checked against the pre-branch pages and against the files and samples involved.
geo-map-binding-data-json-points was read as having lost a JSON-to-model projection. The projection is
gone, and it did not need to be there: the real WorldCities.json has cap, pop, lat, lon, country and name,
so filtering on `cap` and binding `lat` / `lon` reads it directly. What was wrong is the page's Data
Example, which showed `{ "name": "Sydney Island", "lat": ..., "lon": ... }` -- three rows from some other
dataset, without the `cap` the snippet beside it filters on. It now shows rows from the file, including a
capital and a non-capital so the filter has something to mean.
menus/toolbar registered CategoryChartModule and CategoryChartToolbarModule on a page whose every snippet
comes from a DataChart sample. The fence names that sample and then overrode its module list with the
wrong chart's. It now lists what the sample declares, which is also what the topic documented before:
ToolbarModule with the six DataChart modules.
bullet-graph was on the list for dropping IgcBulletGraphCoreModule, where React never listed one. Nothing
to restore: BulletGraphModule registers BulletGraphCoreModule itself, and Angular's module imports and
exports it, so the separate line was redundant and React had it right.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…y what it is The page reached the sparkline through cellUpdatingRef, which taught the event on every platform because that was the only form the library item had. It refers to templateRef now and asks for the template channel, so each platform's page shows its own template: a lit-html one for Web Components, a functional component for React, an ng-template for Angular, and a keyed DataTemplate for the XAML platforms. generate.mjs picked the fence language from the channel alone, so a template whose content is markup was fenced as ts on WPF and WinUI. It now looks at the content: markup gets the platform's markup language whatever channel carried it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…counts as noise auto took exactly one channel and threw if a definition marked two. But a topic teaches one thing and which parts carry it differs by platform: a value written as an attribute on one is assigned in code on another, and a component declared in markup still needs the binding that attaches it to its data. One channel meant whichever parts fell outside it were simply absent. It now asks every channel it is looking for and keeps the ones with content, in the order a reader meets them -- declaration, then imports, then fields, init, binding, handlers. Markup and code are still exclusive, being two ways of saying the same component. Identical blocks are shown once, since a region asked for by name can come back as the whole it belongs to, and a channel a definition cannot answer for is skipped rather than fatal. What it asks for by default is the declaration and the code that completes it. Imports and field declarations are left out of that default and named per fence with include="bindingImports", because which of them belongs is a property of the topic and not of the platform -- some of these pages showed their imports and some left them implied, and conforming to each prior teach is a case by case matter. omit= drops one the same way. No output moves: the one fence in the tree using auto emits the same block on all six platforms, less a blank line that trimming each part removes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Asking a definition for a channel marked descriptions.content and nothing else. A sample places components around the one in the middle -- a toolbar above it, a legend beside it -- and those carry the properties that tie them to it: the toolbar's Target is on the toolbar, not on the chart. So their markup came out and the code that wires them did not, which is why the toolbar topic said "used to link a component ... as shown in the code below" above a block showing an element lookup and no link. All of them are marked now, and the inclusion check asks whether any of them marks itself, so a definition that says what it wants is still left to say it. Two pages move, both the same section: Web Components shows the igc-toolbar beside the chart and toolbar.target = this.chart where it showed the chart's lookup alone, and Blazor gains toolbar.Target in the two places it was missing. Nothing else in the tree changes -- six platforms regenerated to check. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The page said to set highlightedValuesDisplayMode to `Hidden`, and that came out `Hidden` on React, Blazor and WinUI but `hidden` on Web Components and Angular. Bare Hidden resolves as a member with no owner -- something, somewhere, has a hidden property -- and the web platforms camelCase a member name, so the one word the reader is meant to type was rewritten to a value the enum does not have. Escaping it would have stopped that, and lost the link with it. The enum is real and in the maps, under SeriesHighlightedValuesDisplayMode, so the values are qualified by it instead: SeriesHighlightedValuesDisplayMode.Hidden and .Overlay. Both resolve as members of that enum on all five platforms and come out as ApiLinks rather than code spans, identically everywhere. Overlay was already surviving unchanged, so it looked right; it was resolving the same accidental way and qualifying it says what it is. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fifteen tags across en and jp named `triangulationDataSource`, which resolves to nothing on any platform. The rows describe "the source of data items to perform triangulation on if the trianglesSource property provides no triangulation data" -- so it is the series' own data source, and the neighbouring row already documents trianglesSource separately. That member is `dataSource`, and it resolves everywhere: dataSource on Web Components, React and Angular, DataSource on Blazor, ItemsSource on WinUI. The hardcoded label="ItemsSource" goes with it. It was right for the platform the tag was written on and wrong for the three web ones, where the property is dataSource; without it each platform renders its own name, which is what the labelless tags on the same pages already do. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ere were two chart-markers taught its axis wiring as an attribute before the collapse and as a code assignment after, on Web Components only. The mechanism is a choice rather than a defect, so it is stated as one: $styleOptions preferNameBindings puts the reference back in the markup, and x-axis-name="xAxis" is what comes out again, beside React's xAxisName that never moved. chart-annotations and geo-map-display-azure-imagery each carried two fences over one definition -- markup, then the same definition again asking for code -- which is what left React with a second block building a component it does not build that way. One fence with channel="auto" now takes whichever channels the platform has content for, which is what auto is for. Verified on the emitted pages: 304 snippets valid, 758 emissions across five platforms with none failing, 102 fences agreeing with their sample about casing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The combination is the answer to "markup for the element, code for this one property", and nothing said it was available -- the table described each sidecar alone, so the pairing read as a thing to choose between rather than to combine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every platform taught this as label="Time", and the collapsed fence emitted "time": the web emitters camelise a member of the data, and the fence had no way to say otherwise -- skipAlterDataCasing is read off the fence object and this fence was a bare array, which cannot carry it. The includedProperties fence above it sets the flag, which is why "Year" and "USA" survive on the same page while this did not. Written as two named descriptions so the flag has somewhere to sit. Emits label="Time" on Web Components, Angular and React and Label="Time" on Blazor, which is what the four blocks said before. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The layer came out with neither: a data source can only be set in code on Web Components, so it left the markup for a region the element's marker did not name, and the axis reference produced nothing at all. A reader following that block got a layer bound to no data and attached to no axis, while React and Blazor showed both. The element now names the binding regions for Web Components, so the lookup and the assignment come with the markup, and preferNameBindings gives it the target-axis-name attribute React writes -- Angular keeps its own [targetAxis] binding, which is the same wiring in that platform's idiom. The property marker is scoped to Web Components alone. Giving it a "default" as well narrowed every other platform to that one property, because an inclusion marker sets the baseline for the element it sits in: React lost its twelve overlay-text attributes and kept only the data source. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The page said the records "are generated by a ShapefileRecord", that a ShapefileRecord loads the shape files, and that GetPointData belongs to one -- three places where the loader is the ShapeDataSource and the record is what it produces. The API reference list named the record twice and the data source not at all. All of it predates the collapse, which reproduced it faithfully. xValues was written with a capital and resolved as a type of its own, so the first of the three value paths linked to nothing while yValues and values beside it linked to their members. Lowercase, as they are. The Japanese page had these too, plus a "ShapeFileRecord" that is not the spelling of anything. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three dead links on the calendar topic. "Type" was linked as a type of its own: it is the descriptor's RangeType member, and "Type" is only how Web Components spells it -- Angular and React say rangeType, Blazor says RangeType, so freezing one platform's spelling as a type name broke the link on all four. Written canonically now, and each platform renders its own. dateRange was attributed to SparklineGroup, five times, in a link labelled DateRange on a page about DateRangeDescriptor, which has the member. And "first" was a row in the table of CSS parts, beside `date` and `date-inner` in plain code. It is not an API name at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both sections sat inside a block for React and Web Components with a Blazor block nested in them, so a Blazor reader got neither the heading nor the two razor blocks under it -- the DataPipelineParams class the section exists to teach was in the page and reached nobody. The outer block names Blazor now. The inner blocks still divide the platforms, so React and Web Components are unchanged and neither gains a razor block. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The shared expansion runs its own sequence -- component blocks, platform blocks, tokens, image paths -- and never called filterCodeBlocks. So on every grids/_shared page a PlatformBlock was the only thing keeping another platform's code out, and 29 fences were not inside one: Angular markup on the Web Components pages, Web Components markup on the React pages, Angular markup on Blazor's. A reader was being shown code for a framework they are not using. Filtering by language and by content, exactly as a non-shared page is filtered. A fence no pattern claims is untouched, so only what is positively another platform's is removed: foreign fences 29 to 0, with the pages' own counts unchanged. Also unwrapped the block that swallowed "External Advanced Filtering" -- the heading, the demo and the usage prose sat inside a block for Angular alone, so Blazor and Web Components readers lost a section they have content for. Angular's own markup keeps a block of its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…lowed headings
transformMdxFile never called filterCodeBlocks -- only transformRegularFile did, and that path serves
.md files. So no .mdx page in the tree had its code filtered by language or content, and a PlatformBlock
was the only thing keeping another framework's code off a page. Foreign fences across en and jp: 40 to 0.
The cost of getting it right is two fences, both genuinely another platform's.
With that in place, widening a block is safe -- Angular's markup drops out of a Blazor page by content
now, not by enclosure -- so the thirteen blocks that opened straight onto a heading and held other
platforms' content name those platforms. The headings and prose inside them are token-written
({Platform}, {ComponentTitle}) and read the same everywhere; each platform's code still divides on the
inner blocks. Trapped headings: 73 to 14, the first 35 of that being two questions the audit was not
asking rather than anything on a page.
One source bug this uncovered: the DataPipelineParams declaration was shared between React and Web
Components while naming IgcGridLite, so React readers were shown Web Components' type. Filtering alone
would have left React with no declaration at all, so it is split -- IgrGridLite for React, IgcGridLite
for Web Components.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The earlier pass matched a platform block that opened straight onto a heading. These three had a <ComponentBlock> or prose in between, which is the same defect with something in the gap: a block for Angular alone holding React, Web Components and Blazor blocks under five headings, so those readers had the content and not the heading it belongs to. Trapped headings: 0. Foreign fences: 0. Snippet checks unchanged, and the emitter harness stays at 191. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
B2 in the queue: "this.azureMapRef = this.azureMapRef.bind(this);" sat at the top of the React block with nothing declaring azureMapRef, so a bare bind of an invisible method was the first thing a reader met. The fence asked auto for its default channels, which leave the field declarations out. Asking for bindingFields gives the block the field and the ref method above the bind, which is the declaration the line was reaching for -- the same fix Part C applied to the four fences that showed assignments with nothing standing them up. Every platform gains its own declaration; none gains a second copy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Twenty-two English pages carry two blank lines where the Japanese page carries a mentionedTypes line, so the field was stripped from one language and not the other. It is not decoration: resolveApiTerms reads it off the page's own frontmatter as the context behind nearest-in-prose, so a member whose owning type is not named nearby resolves on the Japanese page and renders as bare code on the English one. data-pie-chart is the sharpest case -- 14 SeriesSelectionMode references, the whole SelectionMode option list, linked in Japanese and not in English. Both now read 14. Restored from the Japanese line verbatim rather than composed, so the two cannot drift again by my hand. Across the tree: 4641 ApiLinks to 4704, none lost, and every type gained is one the restored lists name -- no unrelated owner crept in, which was the risk worth checking, since frontmatter context is what resolves a term that prose does not qualify. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Term resolution turned correct plain text into a wrong link, which is worse than leaving it bare: a reader is confidently sent somewhere else. `Overlay` on the data pie chart resolved to the Legend control's overlay property, in a sentence telling you to set the chart's highlightedValuesDisplayMode. Qualified to SeriesHighlightedValuesDisplayMode.Overlay, which is how chart-highlight-filter already writes the same value, and it now renders the same way on both pages. `chartType` on the charts overview resolved to FinancialChart on all six platforms, in the one sentence whose subject is how the category chart differs from it. Qualified to CategoryChart.chartType. The possessive went with it -- "the category chart's CategoryChart.chartType" would read worse than the defect. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Summary fence on row-grouping set autoGenerateColumns to false and stated no columns, so the markup a WinUI or Uno reader copies renders a grid with none. The pre-branch XAML block set no such property and so rendered. The queue records this same defect being found and closed for the two column-chooser sections by stating the sample's columns. That was right there, where the columns are the teaching. Here the section is about grouping summaries, so the property simply goes and the columns generate, which is what the page taught before. Only WinUI and Uno publish this page, so that is the whole blast radius. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The section wires CellValueChanging="DataGridValidateCellEdit" and DataCommitting="DataGridCommitUpdatesOnly", and the fence emitted both bodies into one listing with no signatures at all -- so neither name in the markup appeared in the code, and `var grid = this.grid;` was declared twice in one scope. It would not compile, and a reader could not tell which body was which. omitHandlerSignature is a sensible global default for a section teaching one handler, and wrong for one teaching two. Turned off for this fence only: each body now carries its doc comment and its signature, the names match the attributes above them, and each `var grid` sits in its own method. Swept the tree for the same shape -- a fence declaring one local twice -- and this was the only page. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Numeric Column section says the column "enables control of decimal place placement within cells and displaying fractional digits", and the fence declared a NumericColumn with a field and a header and nothing else, so nothing on the page demonstrated any of it. Pre-branch the XAML block carried PositivePrefix, ShowGroupingSeparator, MaxFractionDigits and MinFractionDigits on a Salary column. The sample has two numeric columns -- a formatted Salary and a plain Age -- and the fence had kept only Age. Salary is back with the sample's own values rather than invented ones, and Age stays: currency formatting on an age column would have been worse than the gap. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
grids/data-grid/overview published the styled TextColumn twice to WinUI and Uno readers: the collapsed fence and, ten lines below it, the hand-written for="Xaml" block it was meant to replace, which was never removed. They disagreed on prefix until the package fix, and the hand-written one was the poorer of the two anyway -- it had the styling without the Field it applies to. The fence carries no exclude, so it already serves the XAML platforms. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"And the control that commits the batch:" and "And the controls that undo and redo them:" stood ungated ahead of blocks for React, Web Components and Blazor. This page is published only for WinUI and Uno, so on every platform that shows it the sentence was followed by the next heading and nothing else. Gated to the same three platforms as their blocks, which is the queue's own rule for this -- it was applied to the handler lead-in further down the same page and not to these two. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Financial / Stock Chart section on the charts overview was ungated, so it rendered on WinUI and Uno with a description, a sample embed and a link to types/stock-chart.mdx. There is no XamFinancialChart in the WinUI public API, and stock-chart.mdx is not published for either platform, so the link was dead and the control unavailable. Gated to the four web platforms. Nothing else on that page was gated, so the pattern is new there; the alternative was leaving a reader to look for a control that does not exist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
WinUI and Uno were served twenty-eight lines of frontmatter and imports as their landing topic -- no headings, no code -- against three hundred and eighteen lines for Web Components. All 101 platform blocks on the page were web-only. Platform blocks rather than a separate document, because Blazor already does exactly this here: a .NET platform whose toolchain shares nothing with Vite and npm, carrying its own six-section install path in this file. A separate document would diverge from a pattern the page already established. What is written is what could be verified. The namespace declarations are taken verbatim from the WinUI sample template, so they match the prefixes every snippet in these topics emits; the target framework and the Windows App SDK prerequisite come from the template's own csproj. What is marked rather than written: the package IDs and feed. nuget.org lists only Infragistics.WinUI.Core and Infragistics.WinUI.Charts at 21.2.36-alpha, docConfig.json names none, and the sample template references the product assemblies directly rather than any customer-facing package. Guessing there would have been worse than the gap. Screenshots and a first-component walkthrough are marked too, in the shape the Blazor section uses. Uno is a separate marked block. Its namespace form is identical but project creation is not -- it has its own solution templates -- so folding both into for="Xaml" would have handed each platform the other's steps. Japanese is deliberately untouched: that page translates every section, including all of Blazor's, so English prose in it would be worse than the gap. This wants translating after review. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The table's columns are DataChart, FinancialChart and CategoryChart, and the two property columns held the same bare backtick, so both resolved the same way -- the FinancialChart column read CategoryChart.yAxisMinimumValue. Nearest-preceding-type context cannot see a column header, which is exactly where a table needs it to. All fourteen rows now qualify their cells, so each is right whatever the prose above happens to name, and the None cells are untouched. The prose two sections up is qualified to CategoryChart, which is what it linked before the branch. The sentence is about "the charts" in general and both types have the properties, so unqualified it was resolving to whichever was named last -- FinancialChart, arbitrarily. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three corrections to the skeleton. WinUI is Ultimate UI, not Ignite UI, and the page already had a token
that says so: {ProductName} resolves to "Infragistics Ultimate UI for WinUI", so the three hardcoded
"Ignite UI for WinUI" strings are now tokens, along with {Platform} for the project heading.
The package IDs are no longer a TODO. They are what this repository packs, from
Source/Nuget/Infragistics.WinUI.*.nuspec -- Core, Charts, DataGrid, Gauges, Inputs, Layouts and
DataVisualization -- paired in a table with the namespace each one wants declared. nuget.org was the
wrong place to look: it carries them only at 21.2.36-alpha.
Two things the nuspecs surfaced and the table does not hide: there is no WinUI maps package in that set
even though the geo-map topics publish for WinUI, and the licensed feed URL still wants confirming. Both
are marked where a reader cannot see them.
The Japanese page has the section too, in house phrasing rather than my own translation. The headings and
lead-in come from the Japanese Blazor section on this same page (## {ProductName} を使用した作業の開始,
### 前提条件, ### 新しい {Platform} プロジェクトの作成, ### {ProductName} のインストール) and, for the two
with no precedent here, from the Japanese Xamarin topic that does exactly this job --
jp.infragistics.com/help/xamarin/xamarin-project-with-infragistics-controls gives 名前空間の追加 and
コントロールの作成. Japanese also keeps that page's own heading levels, which sit one deeper than English.
Uno stays a marked block in both, and now records that its packages come from dotnet pack rather than
the nuspecs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gmurray/winui carries twelve WinUI nuspecs where this branch has seven. The five it adds are exactly the ones whose absence I had written up as an inconsistency: Maps, Dashboards, Sparkline, TreeMap and SkiaSharp. The maps package is not missing, it is on that branch, so the note claiming otherwise is gone. Each package is paired with the namespace a XAML file declares for it, taken from the WinUI public API on that branch rather than guessed: XamSparkline and XamTreemap are both Infragistics.Controls.Charts despite shipping as their own packages, and XamDashboardTile is Infragistics.Controls.Dashboards. The namespace block gained the igDashboards declaration the sample template has and I had left out. The remaining note says what is true: these IDs are the branch's, this branch's Source/Nuget has only seven, and the public feed carries the older ones at 21.2.36-alpha. It wants revisiting when that merges. Also retracted: the Inputs and Layouts descriptions reading "Gauge Components" is already fixed on that branch, so it was a stale copy here rather than something to report. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sixty-nine terms that were ApiLinks before the branch render as bare code now, and they are all the same kind of word: interval, gap, overlap, stroke, brush, value, field, label, start, end, format, range. That is not a bug in resolution, it is resolution working as written -- it refuses an all-lowercase single word on purpose, because the reverse tables are case-insensitive and `label`, `size`, `name` and `icon` are prose far more often than they are API. The pages used to carry these as hand-authored tags, and the reverse pass turned them into backticks where that rule then declines them. Qualifying restores them: `Type.member` needs no context and is not subject to the lowercase rule. The owner for each comes from the tag the page itself carried at bc240f0, so this is the page's own answer rather than mine. 192 terms across 28 pages, mirrored in Japanese, and skipped inside fences and frontmatter. Nine are deliberately left bare. `ValueOverlay.valueMemberPath`, six Sparkline members, `DataPieChart.orientation` and `ShapefileRecord.fields` do not resolve with the owner their old tag gave them -- the queue had already noticed orientation is arguably owned by the ItemLegend rather than the chart. An owner that does not resolve is worse in the source than a bare word, so they stay words until someone says which type they belong to. Links that were lost and now render as code: 69 to 4. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #
Checklist:
preview/beta./page.mdxor../relative/path.mdx(.mdxextension required)IgxSelectComponent,<igx-combo>code blocksfor the names of classes / tags / propertiescode blockscheck-api/mdxnpm commandsllms.descriptionmetadata and runnpm run check:llms-metadata