You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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 touseClassName
, ieuseFireEvent/Errors/Alerts/Callables/etc
, make it aware of the component type so that it exposes the components fields which use a newfastui.events.CallableEvent
field type. Similar to the existing events, a component developer would call the return function that's aware of the availableCallableEvent
fields defined in the component. For example, in theRecorder
typescript component, I might calluseFireEvent<Recorder>().fireCallable('onStopRecording', blobRecordingFormData)
. The two parameters being a type-safe field name 'onMySerializedAliasCallableEventField' optionally along withsomeFormData
. This adding a fast and convenient way for the React page to interact back to the python app. ThefireCallable
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?
The text was updated successfully, but these errors were encountered: