Problem
The LivePreview component's mechanism for identifying the main component to render was overly reliant on a specific code pattern: the explicit assignment of a variable to the output of Neo.setupClass(). This was identified using the findSetupClassName() method.
This approach had two main drawbacks:
Redundant Code in Examples: Functional components created with defineComponent() already have Neo.setupClass() called on them internally. To make them work with LivePreview, they required an extra, redundant MyComponent = Neo.setupClass(MyComponent) line at the end. This introduced unnecessary code and taught a poor coding pattern in our tutorials.
Brittleness: The detection logic was brittle. If a developer forgot the final setupClass() line or wrote it in a slightly different way, the live preview would fail.
Solution
To address this, the component detection logic in LivePreview.mjs has been refactored to be more robust and to promote cleaner example code.
New Detection Method: The findSetupClassName() method has been removed and replaced with findMainClassName().
Convention-over-Configuration: The new method scans the source code for all className declarations. It then uses a convention-based approach to find the main component, searching for class names that end with (in order of priority):
MainContainerMainComponentMainViewMain
Fallback Mechanism: If no class name matching the convention is found, the logic gracefully falls back to using the last className declared in the file. This ensures backward compatibility with existing examples that may not follow the new convention.
Cleaner Code: This change allows us to remove the redundant Neo.setupClass() assignments from our functional component examples, resulting in cleaner, more idiomatic tutorial code. The doRunSource() method was updated to resolve the component instance using its class name string instead of a variable name.
Problem
The
LivePreviewcomponent's mechanism for identifying the main component to render was overly reliant on a specific code pattern: the explicit assignment of a variable to the output ofNeo.setupClass(). This was identified using thefindSetupClassName()method.This approach had two main drawbacks:
Redundant Code in Examples: Functional components created with
defineComponent()already haveNeo.setupClass()called on them internally. To make them work withLivePreview, they required an extra, redundantMyComponent = Neo.setupClass(MyComponent)line at the end. This introduced unnecessary code and taught a poor coding pattern in our tutorials.Brittleness: The detection logic was brittle. If a developer forgot the final
setupClass()line or wrote it in a slightly different way, the live preview would fail.Solution
To address this, the component detection logic in
LivePreview.mjshas been refactored to be more robust and to promote cleaner example code.New Detection Method: The
findSetupClassName()method has been removed and replaced withfindMainClassName().Convention-over-Configuration: The new method scans the source code for all
classNamedeclarations. It then uses a convention-based approach to find the main component, searching for class names that end with (in order of priority):MainContainerMainComponentMainViewMainFallback Mechanism: If no class name matching the convention is found, the logic gracefully falls back to using the last
classNamedeclared in the file. This ensures backward compatibility with existing examples that may not follow the new convention.Cleaner Code: This change allows us to remove the redundant
Neo.setupClass()assignments from our functional component examples, resulting in cleaner, more idiomatic tutorial code. ThedoRunSource()method was updated to resolve the component instance using its class name string instead of a variable name.