feat: message composer

[arnautov-anton]

Message Composer Feature

Overview

This PR introduces a new message composer system that provides a robust foundation for message composition with support for drafts, middleware, and various composition features.

Key Features

• Message draft support for channels
• Text composition middleware system
• Command handling with case-insensitive search
• Link preview integration
• Mentions search with local member support
• Notification management system
• Local message type for better state management

Technical Details

• Introduces MessageComposer class for managing message composition
• Adds middleware system for text composition with extensible pipeline
• Implements draft message handling with proper state management
• Adds support for commands with trigger-based activation
• Integrates link preview functionality during composition
• Provides notification management for composition events
• Introduces LocalMessage type for improved state handling

Breaking Changes

Introduction of LocalMessage type. The MessageResponse is automatically transformed into LocalMessage type before being submitted to the state.

Testing

• Added comprehensive test coverage for:
  • Message composition middleware
  • Command handling
  • Link preview integration
  • Mentions search
  • State management
  • Draft handling

Performance Impact

• Bundle size increase: +72.3 kB (+24.62%)
  • dist/cjs/index.browser.cjs: +19.4 kB
  • dist/cjs/index.node.cjs: +20 kB
  • dist/esm/index.js: +32.9 kB

Future Improvements

• Convert message composer into a plugin system
• Further optimize bundle size
• Add more middleware options for extensibility
• Encapsulate interaction with the UI element representing the text editing area

Related Issues

• Related to stream-chat-react#2669

Dependencies

• linkifyjs@^4.2.0

Documentation

TODO: Add documentation for:

• Message composer API
• Middleware system
• Command handling
• Draft management
• State management

BREAKING CHANGE: Replacement of FormatMessageResponse with LocalMessage type

[github-actions]

Size Change: +80.5 kB (+27.42%) 🚨

Total Size: 374 kB

Filename	Size	Change
dist/cjs/index.browser.cjs	106 kB	+22.2 kB (+26.52%)	🚨
dist/cjs/index.node.cjs	150 kB	+22.8 kB (+17.95%)	⚠️
dist/esm/index.js	119 kB	+35.6 kB (+42.77%)	🚨

_{compressed-size-action}

[arnautov-anton]

I've noticed this pattern a bunch of times here but I don't think this is the route we should take. Any state update emitted by our code should be truly intentional - if we can/have to target specific part of the state, we should do it through the selector which does the value comparation under the hood and the handler gets executed only if the selected values actually changed. It's harder with complex entities (such as arrays or objects) which get constructed anew each time an event comes in with new data and seemingly nothing really changed - but this problem should be tackled at the very top, where the actual state is being changed so that we don't have to re-define these comparisons for every subscription. It's fine like this for now I suppose but we should tackle it at some point.

[MartinCupela]

We are logging the state change timestamp. The goal is to be able to determine, whether the draft data coming through a WS should be accepted and also if a draft creation should take place.

[arnautov-anton]

What I'm trying to say is that the checks should happen here:

on("channel.updated", (event) => {
	const { members, membersHash } = state.getLatestValue();

	members; // ['john', 'bob', 'jane']
	event.members; // also ['john', 'bob', 'jane']

	event.members !== members; // true (overriding these would trigger state update for subscribers with selectors pointing at members)

	const incomingMembersHash = calculateHash(event.members);

	if (membersHash !== incomingMembersHash) { // false (no state change, subscribers won't be notified)
		state.partialNext({
			members: event.members,
			membersHash: incomingMembersHash,
		});
	}
});

The example using hashes is silly but you get the point.

This way - if I create another subscriber (or hundred more) - I can be sure that each won't have to check whether something changed or not, because if their handler got triggered it should mean that something actually changed.

[MartinCupela]

Updated here: 1b13f9a

[stream-ci-bot]

🎉 This PR is included in version 9.2.0-offline-support-beta.1 🎉

The release is available on:

• GitHub release
• npm package (@beta dist-tag)

Your semantic-release bot 📦🚀