Conversation
- autocompleteBar.ts now imports directly from ../../buttons and ../../dragAndDrop - autocompleteField.ts imports from ../../error and ../basic - autocompletePicker.ts imports from ../../error - forms.js no longer imports ../widgets at all
…e source .ts file to the mapped module name 'solid-ui-core/utils/keyHelpers/otherHelpers', which moduleNameMapper resolves to the compiled lib/ file that accessData.js actually imports from.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…aths - Add paths mappings to tsconfig.json so tsc resolves solid-ui-core/* and ui-forms/* sub-path imports - Change import * as ns to import ns (default import) for export= module - Bump solid-ui-core to 0.1.1 (fixes ns.d.ts being copied to lib/) - Use || true in build-types to suppress pre-existing style type errors (style.js uses module.exports interop that tsc can't model without converting to TypeScript — tracked as future work) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
I've taken a look at this PR and the related issues, looking at the code it seems like these are very tied together to SolidOS right now (because they use things like I suppose the reusable web components from https://github.com/SolidOS/solid-web-components shouldn't depend on that, though maybe they can depend on rdflib (this is related with the ongoing discussion to standardize Solid Web Components across different projects like PodOS, etc.). I guess these RDF forms should be reusable as well, not tied together to SolidOS. About releasing them as a separate package or not, I don't have many opinions... Though in general, I'd prefer to keep as few repositories as possible because it's already very difficult to work across different repositories. If we were using a monorepo (hopefully some day we will!) it would be easier to separate things in individual packages, but until that happens I think it's better to rely on tree-shaking for things that share the same concern. In any case, I think the biggest doubt I have at this point is how to handle global state. We can discuss this as we start building the solid-ui "design system" components, because we were saying they should be reusable as well (just not as stylable). But if they depend on global state (like And finally, I see these use the imperative DOM manipulation primitives, so at some point they should be migrated to Web Components as well (if we end up deciding on that). |
2 participants
The forms area part of solid-ui but should really be a separate product. This refactor (done with the help of claude code) moves all the code around but changed nothing in the API of solid-ui. The tests all run still as solid-ui tests, and all pass.