SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsfineui-upgrade

fineui-upgrade

Frontend & websites

View repository

Updated 10-16 06:52

About this skill

FineUI Version Upgrade Skill (Upgrade)

Upgrade an existing FineUI project from an older major version to a higher major version,covering only v10 and above(v9 and below are out of scope).

Version Self-Check (Do First)

  • The built-in high-impact breaking changes list of this skill covers up to v16.0。
  • If the user's target version is higher than v16.0 → Inform the user: this skill may not include breaking changes from newer versions; it is recommended to update this skill first (npx skills update), then continue.
  • If the source version or target version ≤ v9 → Inform the user: this skill only covers v10 and above; for v9 and below, please refer to the official online release history https://fineui.com/versions/ 。

Upgrade Process

Execute in order; do not skip steps.For each step, use square brackets to indicate whether it is "inform the user then continue" or "ask the user and wait".

  1. Determine the version range —— [Ask the user] the current FineUI version and the target version. If the user is unsure of the current version, determine it from the project's FineUI.js version comments, NuGet package version, or web.config/csproj , and [inform the user] of your determination.
  2. Determine the usage style —— [Inform the user] which usage style the project belongs to (F.js / Pro / Core-MVC / Core-RazorForms / Core-RazorPages / Java). For identification clues, see the fineui-foundation skill.Only handle breaking changes relevant to that usage style(in the list, take as needed those marked with [JS]/[Pro]/[Core] ).If the project is FineUI.Java: its first release is v16.0, so there is no "upgrade from an older version" scenario; only the F.js clientbreaking changes it reuses (items in the list marked with [JS] and reflected in the client API/rendering) are relevant to it;C#/.NET-specific [Pro]/[Core] server-side changes do not apply。
  3. Compare against breaking changes —— Read references/breaking-changes.md, and comparewithin the version rangeeach item against the project code. When spanning multiple major versions, go through them version by version, prioritizing the "HTML encoding security mainline" and the v16 event/postback migration.
  4. Generate a migration checklist —— Produce a Markdown file (e.g., FINEUI_UPGRADE_PLAN.md), listing item by item: affected files/code locations, change points,specifically how to change(give before/after).Write the checklist first; do not modify code directly.
  5. Confirm item by item —— [Ask the user] for "behavior change" items (such as HBox height fill, row height definition, DropDownList.Text semantics), confirm item by item whether to accept the new behavior or keep the old behavior; for "rename" items (DateParseString, closeArgument, Active→Activate, etc.), change them directly by default.
  6. Apply changes —— Modify the code according to the confirmed checklist. After finishing, [inform the user] which files were changed.
  7. Verify —— [Inform the user] recommend to the user: on the JS side npm run build-f or run the page directly; for the Core side dotnet build; for the Pro side, compile with VS2022 msbuild; andmanually verifypages affected by HTML encoding (whether the original HTML in menus, titles, and prompts still displays normally).

Reference Documentation

File Content
references/breaking-changes.md List of breaking changes across major v10+ versions + migration methods + HTML encoding main thread

For the complete item-by-item list, refer to the official online release history:https://fineui.com/versions/ (search for "incompatible" in it).

Constraints & Rules

  1. Only handle v10+: when the source/target version is ≤ v9, clearly state that it is not covered.
  2. Produce the list first, then change code: Step 4 produces the migration list and lets the user review it; do not start batch changes right away.
  3. Filter by coding style: a project usually uses only one style, so handle only the breaking changes related to that style;[JS]/[Pro]/[Core] read the annotations carefully.
  4. ESM / class conversion is not a user-facing breaking change: the official v15.0 component-layer ESM conversion and ES2022 class conversion explicitly state that they "do not affect the external API".Do notmodify user code based on this.
  5. HTML encoding is the hardest-hit area: when upgrading across v10 to v16, focus on checking places that originally relied on "text rendered as HTML" (menus, titles, prompts, empty-state EmptyText, message boxes), and change them one by one to trusted HTML declarations (RawHtml, see fineui-foundation rawhtml.md). Distinguish trusted content from user input—do not declare user input as trusted.
  6. Never fabricate changes: when unsure whether a property/method changes in the target version, check the online release history (https://fineui.com/versions/ ) or the official website; do not guess.

Official Resources