Create a collection of folksonomy web component

[alexgarel]

Currently folksonomy is displayed in product opener using a js script.

We would like to move to webcomponents to be able to integrate it in various applications.

There are various questions to be answered:

1. do we develop it in this repository or in folkosnomy_api repository
2. what is the organisation in web-components (avoid being too monolithic)
3. what is the roadmap

[alexgarel]

ROADMAP:

1. reimplement existing
2. Consider sorting user properties table by property (see Consider sorting user properties table by property folksonomy_frontend#9)
3. Add confirmation on deletion (see Is deleting without confirmation too dangerous? folksonomy_frontend#12)
4. Make keys collection sortable by various fields (see Make /keys table sortable by key, count, value folksonomy_frontend#10)
5. Process or wizard to search for an existing property or create a new one (was Process or wizard to search for an existing property or create a new one folksonomy_frontend#18)

[ekas-7]

1. this repository or in folkosnomy_api repository

I recommend developing the web components in this repository due to following reasons :

• Clear separation of concerns - Frontend code lives separately from backend code
• Specialized tooling - Can set up frontend-specific tools without affecting backend
• Targeted documentation - Can focus docs on component usage without API details
• Independent versioning - Can version components based on UI needs, not API changes
• Smaller scope - Easier for new contributors to understand and work with [ SummerofCode can become more collabrative]
• Framework independence - Emphasizes that components can work with any backend implementation

2. Organisation in web-components

Folksonomy Web Components [Initial Version]

Repository Structure

folksonomy-web-components/
├── .github/
│   ├── workflows/
│   │   ├── ci.yml
│   │   ├── release.yml
│   │   └── storybook-deploy.yml
│   └── CODEOWNERS
├── src/
│   ├── components/
│   │   ├── folksonomy-property/
│   │   ├── folksonomy-editor/
│   │   ├── folksonomy-list/
│   │   ├── folksonomy-auth/
│   │   └── folksonomy-stats/
│   ├── utils/
│   │   ├── api-client.js
│   │   └── auth-handler.js
│   └── index.js
├── stories/
├── tests/
├── docs/
├── examples/
├── .eslintrc.js
├── .gitignore
├── package.json
├── README.md
└── LICENSE

Components

• <folksonomy-property>: Display and manage a single property-value pair
• <folksonomy-editor>: Add new properties to products
• <folksonomy-list>: View all properties for a product
• <folksonomy-auth>: Handle authentication with the Folksonomy API
• <folksonomy-stats>: Display statistics about properties usage

ROADMAP

Refer to @alexgarel inputs #32 (comment)

[alexgarel]

Just utils must have folksonomy in their name, because we have other components in the repository

[ekas-7]

Initial Devised Architecture for this repo

|

[ekas-7]

Initial Devised relationship diagram

[alexgarel]

On the point do we develop it in this repository or in folkosnomy_api repository

Putting in folksonomy_api:

• pro: you can develop api feature along with webcomponent modifications
• pro: issues are centralized in folksonomy api
• cons: we have to maintain all the "lit" setup in this other repository (dev server, ci, etc.)

Putting in web-components:

• pro: we have a centralized place for web-components
• pro: we help devs keep API to remain compatible, as the webcomponent is modified in a second phase
• pro: we use the work already done on lit setup
• cons: it might be less evident where issues goes
• cons: it might be less evident to only get one part of the web-components (we could do differentiate packaging though)

[alexgarel]

After discussion with @teolemon we go for option 2: putting in web-components.

[Sunhao86]

I suggest organizing the web components into smaller, focused components instead of one monolithic component:

Core Components

1. <folksonomy-property>

   • Display single folksonomy property
   • Basic property operations (view/edit)

2. <folksonomy-editor>

   • Property editing interface
   • Validation logic
   • Save/cancel actions

3. <folksonomy-list>

   • Display list of folksonomy properties
   • Filtering and sorting
   • Pagination if needed

4. <folksonomy-search>

   • Search interface for properties
   • Auto-complete functionality

Benefits of this structure:

• Each component has a single responsibility
• Users can use only the components they need
• Easier to maintain and test
• Better reusability
• Simpler to integrate into different applications

Usage Example:

<!-- Basic usage -->
<folksonomy-property name="organic"></folksonomy-property>

<!-- Combined usage -->
<folksonomy-list>
  <folksonomy-search></folksonomy-search>
  <folksonomy-editor></folksonomy-editor>
</folksonomy-list>

[Sunhao86]

Building on the component structure suggestion, I'd like to add some thoughts on component communication and API interaction:

Component Communication

1. Event-Based Communication

   • Use custom events for component interaction
   • Bubble events up for container components to handle
   • Keep components decoupled from each other

2. Shared State Management

   • Implement lightweight state sharing when needed
   • Allow components to subscribe to state changes
   • Maintain single source of truth for data

API Interaction

1. Shared API Client

   • Create a reusable API client module
   • Handle authentication and request formatting
   • Centralize error handling logic

2. Configuration Injection

   • Pass API configuration via attributes
   • Allow runtime reconfiguration
   • Support different backend environments

[alexgarel]

@Sunhao86 your comment suggest you didn't look at current code thoroughly.

[alexgarel]

I created #43

I think we should just do edition this way. Finally things like list etc. might be implemented as knowledge panels. What do you think @teolemon