Description
While going through the Recorder component's typescript, refactoring and otherwise cleaning up the code I began thinking about the best way to handle errors. It reminded me of an event system idea I mentioned during an earlier brainstorm. At the time I'd thought of it as a "larger change" although the more I think about it the less complex the solution seems.
If FastUI defined a schema for an endpoint to follow, it would allow tighter integration between a developers FastUI app and the react site being generated. I could imagine adding the support of error handling with the FastUI docs saying: "if you make an endpoint available at 'fui/errors' then any component which supports FastUI Alerts will send them through that endpoint". Then in the npm-fastui project, a hook could be engineered in a similar manner to useClassName, ie useFireEvent/Errors/Alerts/Callables/etc, make it aware of the component type so that it exposes the components fields which use a new fastui.events.CallableEvent field type. Similar to the existing events, a component developer would call the return function that's aware of the available CallableEvent fields defined in the component. For example, in the Recorder typescript component, I might call useFireEvent<Recorder>().fireCallable('onStopRecording', blobRecordingFormData). The two parameters being a type-safe field name 'onMySerializedAliasCallableEventField' optionally along with someFormData. This adding a fast and convenient way for the React page to interact back to the python app. The fireCallable would form a standard return structure and send it to the endpoint, allowing any number of easy handling options for the developer to route the event knowledge/data where it needs to go. A step further, though increasing the complexity, there could be a python FastUI System Endpoint decorator ie: @fastui.system_endpoint, converting standard requests into instances of whichever pydantic class is 'responsible' for calling the system endpoint and the developer could use structural pattern matching to identify/gain access to the component.
This might be completely out of scope for what FastUI is aiming at however, I think it would really enhance the integration available for component designers, even in the simplest implementation of a wrapped alert function that attempts to submit a form to some predefined endpoint that might not exist. As more people begin building sites, I think issues like #64 will become more common.
Anyone have any thoughts?