face-up 0.0.0 → 0.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.gitmodules +3 -0
- package/.kiro/steering/project-context.md +17 -0
- package/.vscode/settings.json +3 -0
- package/FaceUp.js +305 -0
- package/README.md +165 -2
- package/imports.html +8 -0
- package/package.json +30 -20
- package/tests/test1.html +130 -0
- package/types/.kiro/specs/conversion-template/README.md +128 -0
- package/types/.kiro/specs/conversion-template/design.md +360 -0
- package/types/.kiro/specs/conversion-template/requirements.md +191 -0
- package/types/.kiro/specs/conversion-template/tasks.md +174 -0
- package/types/.kiro/steering/coding-standards.md +17 -0
- package/types/.kiro/steering/conversion-guide.md +103 -0
- package/types/.kiro/steering/declarative-configuration.md +108 -0
- package/types/.kiro/steering/emc-json-serializability.md +306 -0
- package/types/EnhancementConversionInstructions.md +1626 -0
- package/types/LICENSE +21 -0
- package/types/NewCustomElementFeature.md +672 -0
- package/types/NewEnhancementInstructions.md +395 -0
- package/types/README.md +2 -0
- package/types/agrace/types.d.ts +11 -0
- package/types/assign-gingerly/types.d.ts +328 -0
- package/types/be-a-beacon/types.d.ts +17 -0
- package/types/be-bound/types.d.ts +61 -0
- package/types/be-buttoned-up/types.d.ts +19 -0
- package/types/be-clonable/types.d.ts +36 -0
- package/types/be-committed/types.d.ts +22 -0
- package/types/be-decked-with/types.d.ts +26 -0
- package/types/be-delible/types.d.ts +25 -0
- package/types/be-reflective/types.d.ts +80 -0
- package/types/be-render-neutral/types.d.ts +29 -0
- package/types/be-typed/types.d.ts +31 -0
- package/types/do-inc/types.d.ts +56 -0
- package/types/do-invoke/types.d.ts +38 -0
- package/types/do-merge/types.d.ts +28 -0
- package/types/do-toggle/types.d.ts +31 -0
- package/types/face-up/types.d.ts +104 -0
- package/types/global.d.ts +29 -0
- package/types/id-generation/types.d.ts +26 -0
- package/types/inferencer/types.d.ts +46 -0
- package/types/mount-observer/types.d.ts +363 -0
- package/types/nested-regex-groups/types.d.ts +101 -0
- package/types/roundabout/types.d.ts +255 -0
- package/types/time-ticker/types.d.ts +66 -0
- package/types/truth-sourcer/types.d.ts +46 -0
|
@@ -0,0 +1,174 @@
|
|
|
1
|
+
# Tasks: Convert [PROJECT_NAME] to Modern Architecture
|
|
2
|
+
|
|
3
|
+
## Task List
|
|
4
|
+
|
|
5
|
+
- [ ] 1. Migrate Type Definitions
|
|
6
|
+
- [ ] 1.1 Check if ts-refs folder exists
|
|
7
|
+
- [ ] 1.2 Copy ts-refs/[project-name] to types/[project-name]
|
|
8
|
+
- [ ] 1.3 Delete ts-refs folder
|
|
9
|
+
- [ ] 1.4 Verify types accessible at new location
|
|
10
|
+
|
|
11
|
+
- [ ] 2. Archive Legacy Implementation
|
|
12
|
+
- [ ] 2.1 Create legacy folder if needed
|
|
13
|
+
- [ ] 2.2 Empty legacy folder if it exists
|
|
14
|
+
- [ ] 2.3 Move all .js files to legacy (except package*.json)
|
|
15
|
+
- [ ] 2.4 Move all .mjs files to legacy
|
|
16
|
+
- [ ] 2.5 Move all .json files to legacy (except package*.json)
|
|
17
|
+
- [ ] 2.6 Verify legacy folder contains complete implementation
|
|
18
|
+
|
|
19
|
+
- [ ] 3. Update package.json
|
|
20
|
+
- [ ] 3.1 Update scripts section with build, serve, test, safari, update
|
|
21
|
+
- [ ] 3.2 Update dependencies to be-hive, mount-observer, and roundabout-lib
|
|
22
|
+
- [ ] 3.3 Update devDependencies to @playwright/test and spa-ssi
|
|
23
|
+
- [ ] 3.4 Run npm run update
|
|
24
|
+
- [ ] 3.5 Verify npm install succeeds
|
|
25
|
+
|
|
26
|
+
- [ ] 4. Configure Import Maps
|
|
27
|
+
- [ ] 4.1 Create or replace imports.html
|
|
28
|
+
- [ ] 4.2 Add assign-gingerly mapping
|
|
29
|
+
- [ ] 4.3 Add project mapping to "/"
|
|
30
|
+
- [ ] 4.4 Add be-hive mapping
|
|
31
|
+
- [ ] 4.5 Add mount-observer mapping
|
|
32
|
+
- [ ] 4.6 Add roundabout-lib mapping
|
|
33
|
+
|
|
34
|
+
- [ ] 5. Establish Coding Standards
|
|
35
|
+
- [ ] 5.1 Create .kiro/steering directory
|
|
36
|
+
- [ ] 5.2 Create coding-standards.md
|
|
37
|
+
- [ ] 5.3 Document import map conventions
|
|
38
|
+
- [ ] 5.4 Document file extension conventions
|
|
39
|
+
- [ ] 5.5 Document TypeScript support conventions
|
|
40
|
+
|
|
41
|
+
- [ ] 6. Modernize Type Definitions
|
|
42
|
+
- [ ] 6.1 Open types/[project-name]/types.d.ts
|
|
43
|
+
- [ ] 6.2 Remove import statements
|
|
44
|
+
- [ ] 6.3 Remove extends IEnhancement from EndUserProps
|
|
45
|
+
- [ ] 6.4 Add enhancedElement: Element to AllProps
|
|
46
|
+
- [ ] 6.5 Remove BAP type alias
|
|
47
|
+
- [ ] 6.6 Replace BAP with AP in Actions interface
|
|
48
|
+
- [ ] 6.7 Verify no TypeScript errors
|
|
49
|
+
|
|
50
|
+
- [ ] 7. Create Build Configuration
|
|
51
|
+
- [ ] 7.1 Create emc.mjs file
|
|
52
|
+
- [ ] 7.2 Add imports and type annotations
|
|
53
|
+
- [ ] 7.3 Configure enhConfig with enhKey and spawn
|
|
54
|
+
- [ ] 7.4 Configure withAttrs for attribute mapping
|
|
55
|
+
- [ ] 7.5 Add weakRef configuration with enhancedElement
|
|
56
|
+
- [ ] 7.6 Copy actions from legacy static config to customData
|
|
57
|
+
- [ ] 7.7 Add 'enhancedElement' to ifAllOf for actions that reference it
|
|
58
|
+
- [ ] 7.8 Copy handlers from legacy static config to customData
|
|
59
|
+
- [ ] 7.9 Copy compacts from legacy static config to customData
|
|
60
|
+
- [ ] 7.10 Add render function
|
|
61
|
+
- [ ] 7.11 Add console.log(render())
|
|
62
|
+
- [ ] 7.12 Test build: npm run build (should generate emc.json)
|
|
63
|
+
|
|
64
|
+
- [ ] 8. Configure VS Code
|
|
65
|
+
- [ ] 8.1 Create .vscode folder if needed
|
|
66
|
+
- [ ] 8.2 Create or open .vscode/settings.json
|
|
67
|
+
- [ ] 8.3 Add file nesting patterns
|
|
68
|
+
- [ ] 8.4 Enable file nesting
|
|
69
|
+
- [ ] 8.5 Verify JSON files nest under .mjs files in explorer
|
|
70
|
+
|
|
71
|
+
- [ ] 8a. Configure Auto-Build Hook (Optional)
|
|
72
|
+
- [ ] 8a.1 Create .kiro/hooks folder if needed
|
|
73
|
+
- [ ] 8a.2 Create auto-build-config.kiro.hook
|
|
74
|
+
- [ ] 8a.3 Configure fileEdited event for emc.mjs and emoji .mjs
|
|
75
|
+
- [ ] 8a.4 Configure runCommand action with npm run build
|
|
76
|
+
- [ ] 8a.5 Test by saving emc.mjs and verifying JSON regenerates
|
|
77
|
+
|
|
78
|
+
- [ ] 9. Create Modern Enhancement Class
|
|
79
|
+
- [ ] 9.1 Create be-[project-name].js file
|
|
80
|
+
- [ ] 9.2 Add imports (emc.json with type annotation, types)
|
|
81
|
+
- [ ] 9.3 Add class declaration
|
|
82
|
+
- [ ] 9.4 Add constructor with enhancedElement, ctx, initVals parameters
|
|
83
|
+
- [ ] 9.5 Add init method with enhancedElement parameter
|
|
84
|
+
- [ ] 9.6 Add roundabout integration in init
|
|
85
|
+
- [ ] 9.7 Add enhancedElement to assignGingerly call
|
|
86
|
+
- [ ] 9.8 Add default values to init via assignGingerly
|
|
87
|
+
- [ ] 9.9 Copy action methods from legacy
|
|
88
|
+
- [ ] 9.10 Replace BAP with AP in all methods
|
|
89
|
+
- [ ] 9.11 Remove legacy imports
|
|
90
|
+
- [ ] 9.12 Export class
|
|
91
|
+
- [ ] 9.13 Verify no TypeScript errors
|
|
92
|
+
|
|
93
|
+
- [ ] 10. Create Emoji Shorthand (Optional)
|
|
94
|
+
- [ ] 10.1 Check README for emoji in title
|
|
95
|
+
- [ ] 10.2 Create [emoji].mjs file (if emoji exists)
|
|
96
|
+
- [ ] 10.3 Import emc.json
|
|
97
|
+
- [ ] 10.4 Configure enhConfig override
|
|
98
|
+
- [ ] 10.5 Add render function
|
|
99
|
+
- [ ] 10.6 Add console.log(render())
|
|
100
|
+
- [ ] 10.7 Test build: npm run build (should generate [emoji].json)
|
|
101
|
+
|
|
102
|
+
- [ ] 11. Verification
|
|
103
|
+
- [ ] 11.1 Run npm run build (should succeed)
|
|
104
|
+
- [ ] 11.2 Verify emc.json generated
|
|
105
|
+
- [ ] 11.3 Verify [emoji].json generated (if applicable)
|
|
106
|
+
- [ ] 11.4 Run npm test (should pass)
|
|
107
|
+
- [ ] 11.5 Check for TypeScript errors
|
|
108
|
+
- [ ] 11.6 Verify legacy folder is complete
|
|
109
|
+
- [ ] 11.7 Compare behavior with legacy implementation
|
|
110
|
+
|
|
111
|
+
## Task Dependencies
|
|
112
|
+
|
|
113
|
+
```
|
|
114
|
+
1 (Types) → 6 (Modernize Types)
|
|
115
|
+
2 (Archive) → 7 (Build Config), 9 (Enhancement Class)
|
|
116
|
+
3 (package.json) → 7 (Build Config)
|
|
117
|
+
4 (imports.html) → 9 (Enhancement Class)
|
|
118
|
+
5 (Standards) → 9 (Enhancement Class)
|
|
119
|
+
6 (Types) → 7 (Build Config), 9 (Enhancement Class)
|
|
120
|
+
7 (Build Config) → 9 (Enhancement Class), 10 (Emoji)
|
|
121
|
+
8 (VS Code) → (no dependencies, can be done anytime)
|
|
122
|
+
9 (Enhancement Class) → 11 (Verification)
|
|
123
|
+
10 (Emoji) → 11 (Verification)
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
## Execution Notes
|
|
127
|
+
|
|
128
|
+
### Step 1: Migrate Type Definitions
|
|
129
|
+
- Check for ts-refs folder first
|
|
130
|
+
- If not found, types may already be migrated
|
|
131
|
+
- Verify types are accessible after migration
|
|
132
|
+
|
|
133
|
+
### Step 2: Archive Legacy Implementation
|
|
134
|
+
- This is critical - don't skip
|
|
135
|
+
- Verify all files are moved before proceeding
|
|
136
|
+
- Keep package.json and package-lock.json in root
|
|
137
|
+
|
|
138
|
+
### Step 3: Update package.json
|
|
139
|
+
- Note the emoji in README title for build script
|
|
140
|
+
- If no emoji, omit the emoji build command
|
|
141
|
+
- npm run update will fetch latest versions
|
|
142
|
+
|
|
143
|
+
### Step 7: Create Build Configuration
|
|
144
|
+
- Reference legacy emc.js for base/branches/map
|
|
145
|
+
- Reference legacy be-*.js static config for actions/handlers/compacts
|
|
146
|
+
- Add weakRef configuration with enhancedElement at minimum
|
|
147
|
+
- For actions with ifAllOf, add 'enhancedElement' if the method code references it
|
|
148
|
+
- Don't copy propDefaults or propInfo
|
|
149
|
+
- Test the build immediately after creating
|
|
150
|
+
|
|
151
|
+
### Step 9: Create Modern Enhancement Class
|
|
152
|
+
- No WeakRef boilerplate needed - roundabout handles it
|
|
153
|
+
- Constructor passes enhancedElement to init method
|
|
154
|
+
- Init method receives enhancedElement as parameter
|
|
155
|
+
- Add enhancedElement to assignGingerly call before other defaults
|
|
156
|
+
- Copy action methods carefully
|
|
157
|
+
- Replace all BAP with AP
|
|
158
|
+
- Keep method implementations the same
|
|
159
|
+
- Remove any be-enhanced specific code
|
|
160
|
+
|
|
161
|
+
### Step 10: Create Emoji Shorthand
|
|
162
|
+
- Only if emoji exists in README title
|
|
163
|
+
- Very simple - just overrides enhKey and base
|
|
164
|
+
- Test build to verify JSON generation
|
|
165
|
+
|
|
166
|
+
### Step 11: Verification
|
|
167
|
+
- This is the final validation
|
|
168
|
+
- All tests should pass
|
|
169
|
+
- Build should succeed
|
|
170
|
+
- No TypeScript errors
|
|
171
|
+
|
|
172
|
+
## Reference
|
|
173
|
+
|
|
174
|
+
For detailed instructions on each step, see: `#[[file:../../ConversionInstructions.md]]`
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
# Coding Standards
|
|
2
|
+
|
|
3
|
+
## JavaScript Module Conventions
|
|
4
|
+
|
|
5
|
+
### Import Maps
|
|
6
|
+
- Use import maps with explicit, bare specifiers ending with `*.js` for all JavaScript references that run in the browser
|
|
7
|
+
- Example: `"be-hive/": "/node_modules/be-hive/"`
|
|
8
|
+
|
|
9
|
+
### File Extensions
|
|
10
|
+
- Use `*.mjs` files exclusively for npm build scripts, not for browser code
|
|
11
|
+
- Use `*.js` files (not `*.ts`) for all browser-executable code
|
|
12
|
+
- Enable TypeScript support in `*.js` files via `@ts-check` directive at the top of files
|
|
13
|
+
|
|
14
|
+
### TypeScript Support
|
|
15
|
+
- Add `// @ts-check` at the beginning of JavaScript files to enable TypeScript checking
|
|
16
|
+
- Use JSDoc comments for type annotations when needed
|
|
17
|
+
- Leverage type definitions from the `types` submodule
|
|
@@ -0,0 +1,103 @@
|
|
|
1
|
+
# be-* Enhancement Conversion Guide
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
This steering file provides guidance for converting legacy "be-*" enhancement projects to the modern architecture. When a user requests help with converting a be-* project, use this guide to structure the conversion process.
|
|
6
|
+
|
|
7
|
+
**Important:** This guide is specifically for **enhancements** (declarative behaviors added to existing HTML elements via attributes). It does NOT apply to custom elements.
|
|
8
|
+
|
|
9
|
+
## Reference Documentation
|
|
10
|
+
|
|
11
|
+
- **Converting legacy enhancements:** `EnhancementConversionInstructions.md` in the types repository root
|
|
12
|
+
- **Creating new enhancements from scratch:** `NewEnhancementInstructions.md` in the types repository root
|
|
13
|
+
|
|
14
|
+
Always reference the appropriate document based on whether the project is a legacy conversion or a brand new enhancement.
|
|
15
|
+
|
|
16
|
+
## Conversion Approach
|
|
17
|
+
|
|
18
|
+
### When to Use Spec-Based Conversion
|
|
19
|
+
|
|
20
|
+
For systematic, trackable conversions, create a spec using the conversion template:
|
|
21
|
+
- User wants to track progress through the conversion
|
|
22
|
+
- User wants to review each step before proceeding
|
|
23
|
+
- User is learning the conversion process
|
|
24
|
+
- Multiple people are involved in the conversion
|
|
25
|
+
|
|
26
|
+
### When to Use Direct Conversion
|
|
27
|
+
|
|
28
|
+
For quick, automated conversions:
|
|
29
|
+
- User is familiar with the conversion process
|
|
30
|
+
- User wants rapid execution without step-by-step review
|
|
31
|
+
- The project is straightforward with no special cases
|
|
32
|
+
|
|
33
|
+
## Key Principles
|
|
34
|
+
|
|
35
|
+
1. **Preserve Legacy Code**: Always move existing implementation to the `legacy` folder before making changes
|
|
36
|
+
2. **Follow the Order**: The conversion steps have dependencies - follow them in sequence
|
|
37
|
+
3. **Verify Each Step**: After each major step, verify the changes work as expected
|
|
38
|
+
4. **Reference Examples**: Point to **be-clonable** (most up-to-date), be-committed, and be-decked-with as reference implementations. Prefer be-clonable as it has the latest architectural improvements. Note: be-a-beacon is too simple to serve as a good example - it doesn't use roundabout due to its minimal requirements.
|
|
39
|
+
|
|
40
|
+
## Common Patterns
|
|
41
|
+
|
|
42
|
+
### Project Structure Recognition
|
|
43
|
+
|
|
44
|
+
Identify legacy projects by these characteristics:
|
|
45
|
+
- Has `be-enhanced` or `trans-render` dependencies
|
|
46
|
+
- Class extends `BE` from be-enhanced
|
|
47
|
+
- Has static `config` object in the enhancement class
|
|
48
|
+
- Uses `emc.js` with `base`, `branches`, `map` pattern
|
|
49
|
+
- Has `ts-refs` submodule for types
|
|
50
|
+
|
|
51
|
+
### Modern Architecture Indicators
|
|
52
|
+
|
|
53
|
+
Recognize already-converted projects by:
|
|
54
|
+
- Has `be-hive` and `roundabout-lib` dependencies
|
|
55
|
+
- Has `emc.mjs` build script
|
|
56
|
+
- Has `types` submodule (not `ts-refs`)
|
|
57
|
+
- Class doesn't extend anything
|
|
58
|
+
- Uses constructor with `enhancedElement`, `ctx`, `initVals` parameters
|
|
59
|
+
|
|
60
|
+
## Conversion Workflow
|
|
61
|
+
|
|
62
|
+
When a user asks to convert a be-* project:
|
|
63
|
+
|
|
64
|
+
1. **Assess the project**: Determine if it's legacy or already converted
|
|
65
|
+
2. **Offer spec creation**: Ask if they want a tracked conversion (spec) or direct conversion
|
|
66
|
+
3. **Execute systematically**: Follow the 10 steps in ConversionInstructions.md
|
|
67
|
+
4. **Run npm run update**: After Step 3 (updating package.json), ALWAYS run `npm run update` to install dependencies before proceeding
|
|
68
|
+
5. **Verify at milestones**: After steps 3, 7, and 10, suggest running `npm run build` and `npm test`
|
|
69
|
+
6. **Reference the guide**: Point users to specific sections of ConversionInstructions.md as needed
|
|
70
|
+
7. **Use be-clonable as reference**: When implementation details are unclear, refer to [be-clonable](https://github.com/bahrus/be-clonable) as it has the most refined patterns
|
|
71
|
+
|
|
72
|
+
## Special Cases
|
|
73
|
+
|
|
74
|
+
### No Emoji Shorthand
|
|
75
|
+
If the README doesn't have an emoji in the title:
|
|
76
|
+
- Skip Step 10 (emoji .mjs creation)
|
|
77
|
+
- Update package.json build script to only generate emc.json
|
|
78
|
+
|
|
79
|
+
### Complex Static Config
|
|
80
|
+
If the legacy static config has unusual patterns:
|
|
81
|
+
- Carefully map `propDefaults` to the init method
|
|
82
|
+
- Preserve any custom logic in action methods
|
|
83
|
+
- Document any patterns that don't fit the standard conversion
|
|
84
|
+
|
|
85
|
+
### Custom Dependencies
|
|
86
|
+
If the project uses trans-render utilities:
|
|
87
|
+
- Keep those imports in the action methods
|
|
88
|
+
- Don't remove them unless they're only used in static config
|
|
89
|
+
|
|
90
|
+
## Success Criteria
|
|
91
|
+
|
|
92
|
+
A successful conversion should:
|
|
93
|
+
- ✅ Build without errors (`npm run build`)
|
|
94
|
+
- ✅ Pass existing tests (`npm test`)
|
|
95
|
+
- ✅ Have all legacy files in the `legacy` folder
|
|
96
|
+
- ✅ Have modern architecture files (emc.mjs, be-*.js, types)
|
|
97
|
+
- ✅ Have updated dependencies (be-hive, roundabout-lib)
|
|
98
|
+
- ✅ Generate valid JSON configuration files
|
|
99
|
+
|
|
100
|
+
## File Reference
|
|
101
|
+
|
|
102
|
+
Always reference `#[[file:EnhancementConversionInstructions.md]]` for the complete step-by-step conversion instructions.
|
|
103
|
+
For new enhancements, reference `#[[file:NewEnhancementInstructions.md]]`.
|
|
@@ -0,0 +1,108 @@
|
|
|
1
|
+
# Declarative Configuration Principle
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
Move as much "code" out of JavaScript into JSON configuration as possible. JSON is faster to parse than JavaScript, and declarative configuration makes the code more maintainable and easier to understand.
|
|
6
|
+
|
|
7
|
+
## When to Apply
|
|
8
|
+
|
|
9
|
+
This principle applies when:
|
|
10
|
+
- Creating or configuring DOM elements with known properties
|
|
11
|
+
- Setting element attributes, classes, or other properties
|
|
12
|
+
- The logic is primarily about setting values rather than complex computation
|
|
13
|
+
|
|
14
|
+
## Pattern: Element Creation Settings
|
|
15
|
+
|
|
16
|
+
Instead of imperatively creating and configuring elements in JavaScript:
|
|
17
|
+
|
|
18
|
+
```javascript
|
|
19
|
+
// ❌ Imperative approach
|
|
20
|
+
async addDeleteBtn(self){
|
|
21
|
+
// ... find or create trigger ...
|
|
22
|
+
if(trigger === null){
|
|
23
|
+
trigger = document.createElement('button');
|
|
24
|
+
trigger.type = 'button';
|
|
25
|
+
trigger.classList.add('be-delible-trigger');
|
|
26
|
+
trigger.ariaLabel = 'Delete this.';
|
|
27
|
+
trigger.title = 'Delete this.';
|
|
28
|
+
enhancedElement.insertAdjacentElement(triggerInsertPosition, trigger);
|
|
29
|
+
}
|
|
30
|
+
return { trigger: new WeakRef(trigger), byob };
|
|
31
|
+
}
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Move the configuration to JSON in emc.mjs:
|
|
35
|
+
|
|
36
|
+
```javascript
|
|
37
|
+
// ✅ Declarative approach in emc.mjs
|
|
38
|
+
customData: {
|
|
39
|
+
customData: {
|
|
40
|
+
triggerSettings: {
|
|
41
|
+
type: 'button',
|
|
42
|
+
'?.classList?.add': 'be-delible-trigger',
|
|
43
|
+
ariaLabel: 'Delete this.',
|
|
44
|
+
title: 'Delete this.',
|
|
45
|
+
},
|
|
46
|
+
withMethods: ['add']
|
|
47
|
+
}
|
|
48
|
+
}
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
Then use assignGingerly to apply the settings:
|
|
52
|
+
|
|
53
|
+
```javascript
|
|
54
|
+
// ✅ Simplified JavaScript
|
|
55
|
+
async addDeleteBtn(self) {
|
|
56
|
+
// ... find or create trigger ...
|
|
57
|
+
if (trigger === null) {
|
|
58
|
+
trigger = document.createElement('button');
|
|
59
|
+
const {triggerSettings, withMethods} = customData.customData;
|
|
60
|
+
(await import('assign-gingerly/assignGingerly.js')).assignGingerly(trigger, triggerSettings, {withMethods});
|
|
61
|
+
enhancedElement.insertAdjacentElement(triggerInsertPosition, trigger);
|
|
62
|
+
}
|
|
63
|
+
return { trigger, resolved: true, byob };
|
|
64
|
+
}
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
## Benefits
|
|
68
|
+
|
|
69
|
+
1. **Performance**: JSON parsing is faster than JavaScript execution
|
|
70
|
+
2. **Maintainability**: Configuration is centralized and easier to modify
|
|
71
|
+
3. **Clarity**: Declarative intent is clearer than imperative code
|
|
72
|
+
4. **Separation of concerns**: Configuration is separate from logic
|
|
73
|
+
|
|
74
|
+
## assignGingerly Special Syntax
|
|
75
|
+
|
|
76
|
+
The `assignGingerly` utility supports special property syntax:
|
|
77
|
+
|
|
78
|
+
- `'?.classList?.add'`: Safely calls `classList.add()` method
|
|
79
|
+
- `'?.classList?.remove'`: Safely calls `classList.remove()` method
|
|
80
|
+
- `'?.classList?.toggle'`: Safely calls `classList.toggle()` method
|
|
81
|
+
- Use `withMethods` option to specify which methods to enable (e.g., `{withMethods: ['add', 'remove']}`)
|
|
82
|
+
|
|
83
|
+
## WeakRef Handling
|
|
84
|
+
|
|
85
|
+
When using roundabout's `weakRef.properties` configuration:
|
|
86
|
+
|
|
87
|
+
- Properties listed in `weakRef.properties` are automatically wrapped in WeakRef by roundabout
|
|
88
|
+
- In your action methods, access these properties directly (roundabout unwraps them automatically)
|
|
89
|
+
- Return the raw element reference, not `new WeakRef(element)` - roundabout handles the wrapping
|
|
90
|
+
|
|
91
|
+
```javascript
|
|
92
|
+
// ✅ Correct - return raw element
|
|
93
|
+
return { trigger, resolved: true, byob };
|
|
94
|
+
|
|
95
|
+
// ❌ Wrong - don't manually wrap in WeakRef
|
|
96
|
+
return { trigger: new WeakRef(trigger), resolved: true, byob };
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
## When NOT to Apply
|
|
100
|
+
|
|
101
|
+
Don't force declarative configuration when:
|
|
102
|
+
- The logic involves complex conditionals or computations
|
|
103
|
+
- The configuration depends on runtime state that can't be known at build time
|
|
104
|
+
- The imperative code is actually clearer and simpler
|
|
105
|
+
|
|
106
|
+
## Reference Implementation
|
|
107
|
+
|
|
108
|
+
See [be-clonable](https://github.com/bahrus/be-clonable/blob/baseline/emc.mjs) for a complete example of this pattern in action.
|