Move page-editor-specific widgets to @/pageEditor

[fregante]

• From #4694: Warn when shared modules import context-specific modules #4728 (comment)

IIRC, SelectorMatchWidget only works in a Page Editor context, because it includes selector fields. Although, it might work in other contexts and just show a plain text field. So it's easiest to assume it should live in the Page Editor subdirectory

CssClassWidget is also only used in the Page Editor currently. Although, it doesn't depend on any field widgets that are page-editor specific

Long term, we'd likely have 2 folders:

• Universal Widgets that work in any context
• Page Editor-specific widgets that take advantage of the Page Editor context

Related:

• Prevent context-specific code from being imported in the wrong context #669

[fregante]

Also potential improvement in #4728 (comment)

Would it make sense to move @/contrib/uipath/LocalProcessOptions.tsx to @/pageEditor?

Can we find a (naming?) pattern that helps us maintain safety? For example LocalProcessOptions.pageEditor.tsx would be enforceable via our eslint rule, rather than being an unsafe exception:

• Add eslint rule to prevent banned imports from utils directory #4694

[BLoe]

@grahamlangford Not sure how this specific ticket fits into our more general effort around modules and the import lint rules, but should probably be closed in favor of more comprehensive lint-rule/module/folder-structure changes I think? Maybe worth keeping around and tracking as a key-result of that work? Meaning, make sure this specific situation is handled.

[github-actions]

This issue will be closed in 7 days unless the stale label is removed, or a comment is added to the issue.

[github-actions]

This issue was closed because it has been stale for 7 days with no activity.

[fregante]

This is still useful in the context of enforcing imports in the right context via no-restricted-paths:

• Forbid expectContext/forbidContext in folders that already enforce it eslint-config-pixiebrix#193

It's a low-risk "quick" change because it just involves moving files around.

Proposed steps

1. Search for the pageEditor/ string in /components files
2. Move all the matched components to @/pageEditor/components

Also maybe:

3. Move any remaining components that are only meant to be used in the page editor, even if they don't use pageEditor-specific APIs

[github-actions]

This issue will be closed in 7 days unless the stale label is removed, or a comment is added to the issue.

[grahamlangford]

@BLoe considering our Engineering Metrics conversation, this seems like an issue we should pick up as a quick 30% time

[BLoe]

Yeah probably worth doing, although this ticket as described might be a huge scope 🤷

[grahamlangford]

Yeah probably worth doing, although this ticket as described might be a huge scope 🤷

I'm open to breaking it up into multiple issues or PRs.

[twschiller]

I opened two PRs to close out this issue for now:

• #4887: move document builder to pageEditor directory #8629
• #4887: move add brick modal to pageEditor and rename #8628

Would it make sense to move @/contrib/uipath/LocalProcessOptions.tsx to @/pageEditor? Can we find a (naming?) pattern that helps us maintain safety? For example LocalProcessOptions.pageEditor.tsx

For developer ergonomics, we want to keep the concerns local. I'd be in favor of introducing a naming rule like LocalProcessOptions.pageEditor.tsx to allow automatic enforcement via

A similar issue comes up with the document builder. The render directory contains code that is used outside of the page editor. We could introduce a shared directory naming convention for utilities/components that need to be "exported" from a context

I've created follow up issue here to enforce as a rule: #8630