Let me analyze the key changes in this diff:
1. **Role System Changes**:
- Changed from a fixed enum of roles (`root`, `hub`, `content`) to a more flexible string-based system
- Removed strict role hierarchy validation rules (hub/content/root relationships)
- Added support for role-based matching using `@` prefix (e.g., `@root`, `@content`)
2. **Schema Validation Updates**:
- Added new `_matchFlavourOrRole` method to handle both flavour and role-based matching
- Updated `_validateParent` to consider both roles and flavours when validating parent-child relationships
- Simplified `_validateRole` by removing specific role hierarchy constraints
3. **Block Schema Changes**:
- Updated parent/children references in various block schemas to use the new `@` prefix notation
- Changed parent definitions from `['affine:page']` to `['@root']` in several blocks
- Updated children definitions to use role-based references (e.g., `['@content']`)
4. **Test Updates**:
- Added new test cases for role-based schema validation
- Introduced new test block schemas (`TestRoleBlockSchema`, `TestParagraphBlockSchema`) to verify role-based functionality
This appears to be a significant architectural change that makes the block schema system more flexible by:
1. Moving away from hardcoded role hierarchies
2. Introducing a more dynamic role-based relationship system
3. Supporting both flavour-based and role-based parent-child relationships
4. Using the `@` prefix convention to distinguish role references from flavour references
The changes make the system more extensible while maintaining backward compatibility with existing flavour-based relationships.
### Changed
- Refactored BlockSuite drag-and-drop using @atlaskit/pragmatic-drag-and-drop/element/adapter.
- Updated block dragging to use the new drag-and-drop infrastructure.
### BlockSuite DND API
Access the BlockSuite drag-and-drop API via `std.dnd`. This is a lightweight wrapper around pragmatic-drag-and-drop, offering convenient generic types and more intuitive option names.
#### Drag payload structure
There's some constrain about drag payload. The whole drag payload looks like this:
```typescript
type DragPayload = {
entity: {
type: string
},
from: {
at: 'blocksuite',
docId: string
}
}
```
- The `from` field is auto-generated—no need for manual handling.
- The `entity` field is customizable, but it must include a `type`.
All drag-and-drop methods accept a generic type for entity, ensuring more accurate payloads in event handlers.
```typescript
type BlockEntity = {
type: 'blocks',
blockIds: string[]
}
dnd.draggable<BlockEntity>({
element: someElement,
setDragData: () => {
// the return type must satisfy the generic type
// in this case, it's BlockEntity
return {
type: 'blocks',
blockIds: []
}
}
});
dnd.monitor<BlockEntity>({
// the arguments is same for other event handler
onDrag({ source }) {
// the type of this is BlockEntity
source.data.entity
}
})
```
#### Drop payload
When hover on droppable target. You can set drop payload as well. All drag-and-drop methods accept a second generic type for drop payload.
The drop payload is customizable. Additionally, the DND system will add an `edge` field to the final payload object, indicating the nearest edge of the drop target relative to the current drag position.
```typescript
type DropPayload = {
blockId: string;
}
dnd.dropTarget<BlockEntity, DropPayload>({
getData() {
// the type should be DropPayload
return {
blockId: 'someId'
}
}
});
dnd.monitor<BlockEntity, DropPayload>({
// drag over on drop target
onDrag({ location }) {
const target = location.current.dropTargets[0];
// the type is DropPayload
target.data;
// retrieve the nearest edge of the drop target relative to the current drop position.
target.data.edge;
}
})
```
