Suggestion: Split OakUiNodeBuilders.kt into smaller category-specific files

[adrielGGmotion]

Suggestion: Split OakUiNodeBuilders.kt into smaller category-specific files

Category: Code organization
File: composeApp/src/commonMain/kotlin/com/oak/app/model/OakUiNodeBuilders.kt

OakUiNodeBuilders.kt is 629 lines and contains approximately 30 parse*Node private functions that map JSON tree nodes to UI components. Following the same pattern established by issue #64 (OakUiRenderer.kt split), this file should be decomposed into category-specific builder files (e.g., TextNodeBuilder.kt, TableNodeBuilder.kt, LayoutNodeBuilder.kt, FormNodeBuilder.kt) to improve navigability and maintainability.

Suggested action: Split the node builder functions into multiple files grouped by UI component category, keeping only the shared orchestration logic in OakUiNodeBuilders.kt.

[adrielGGmotion]

@coderabbitai what do you think

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

gh issue view 85 --repo adrielGGmotion/Oak --comments

Length of output: 299

---

🏁 Script executed:

gh issue view 85 --repo adrielGGmotion/Oak --json title,body,comments

Length of output: 1543

---

🏁 Script executed:

fd OakUiNodeBuilders.kt

Length of output: 241

---

🏁 Script executed:

ast-grep outline composeApp/src/commonMain/kotlin/com/oak/app/ui/dynamicui/OakUiNodeBuilders.kt --items all --type function
wc -l composeApp/src/commonMain/kotlin/com/oak/app/ui/dynamicui/OakUiNodeBuilders.kt

Length of output: 4465

---

@adrielGGmotion Took a pass through the file to size this up before giving an opinion — here's what I found and my take.

Confirmed the numbers: OakUiNodeBuilders.kt is 629 lines with ~29 private parse*Node functions (one per UI node type — parseColumnNode, parseTextNode, parseButtonNode, parseTableNode, parseAccordionNode, etc.), plus the parseNode/parseObjectNode dispatcher, some enum parsers (parseTextStyle, parseButtonVariant, parseAlertSeverity), and a decent chunk of shared internal extension functions on JsonObject/JsonElement (readString, readId, readNodeList, readAction, readCallbackDataMap, etc.).

I agree with the suggestion — this is a good split candidate and follows the same shape as the #64 renderer split. My concrete proposal:

1. Keep in OakUiNodeBuilders.kt: the parseNode/parseObjectNode dispatcher (the when block routing by type), inferBareObject, and the shared JsonObject/JsonElement extension helpers — these are cross-cutting utilities every category file will need, so splitting them out or duplicating them would add more indirection than it removes.
2. New category files, each holding the relevant parse*Node functions:
   • LayoutNodeBuilder.kt → Column, Row, Card, Box, Divider
   • TextContentNodeBuilder.kt → Text, Image, Icon, Code, Quote, Badge, Stat, Avatar
   • InputNodeBuilder.kt → Button, TextInput, Checkbox, Select, Switch, Slider, RadioGroup, ChipGroup
   • DisplayNodeBuilder.kt → Progress, Alert, Countdown, List, Table, Tabs, Accordion

Since the parse*Node functions are private, they'd need to become internal (visible within the module) once moved to separate files, which is a minor but necessary change — worth calling out in the PR.

This should keep each file in the 100–200 line range and make it easier to find/modify a specific component's parsing logic without scrolling through unrelated node types. Happy to help sanity-check a PR if you (or someone) picks this up.

ᕦ(ò_óˇ)ᕤ