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
Currently, fabrix still has several things that it cannot do but are needed on production usecase.
Things needed are:
Render forms for Query operation
Render result for Mutation operation
Re-execute query (refetch)
Flexibility to place form components (with JSX expression)
Form validation
Overall design
To tackle on those requirements, it comes to my mind of the idea to restructure the interface that FabrixComponent currently has to have more abstract, flexible interface to achive what we need.
Abstractness here is that: FabrixComponent does not have to be aware of the operation type anymore. Even if if is Query, it can have forms to get inputs, and also even if it is Mutation, it can have view to see the results. The current design splits them out, but new design handles them as the same internal mechanism in rendering it into the component.
FabrixComponent now has two following functions to get componets to render as follows.
getInput
A renderer function for forms inferred from GraphQL variables.
getInput automatically renders a view of form (including submit button) if no render prop. Giving the render props allows users to customize the form in a component-level flexibility. This function is also a point to inject validation rules that you want to add, and some functions hooks on executing queries.
getOutput
A renderer function for GraphQL response.
Design image
The text was updated successfully, but these errors were encountered:
Background
Currently, fabrix still has several things that it cannot do but are needed on production usecase.
Things needed are:
Query
operationMutation
operationOverall design
To tackle on those requirements, it comes to my mind of the idea to restructure the interface that
FabrixComponent
currently has to have more abstract, flexible interface to achive what we need.Abstractness here is that:
FabrixComponent
does not have to be aware of the operation type anymore. Even if if isQuery
, it can have forms to get inputs, and also even if it isMutation
, it can have view to see the results. The current design splits them out, but new design handles them as the same internal mechanism in rendering it into the component.FabrixComponent
now has two following functions to get componets to render as follows.getInput
A renderer function for forms inferred from GraphQL variables.
getInput
automatically renders a view of form (including submit button) if no render prop. Giving the render props allows users to customize the form in a component-level flexibility. This function is also a point to inject validation rules that you want to add, and some functions hooks on executing queries.getOutput
A renderer function for GraphQL response.
Design image
The text was updated successfully, but these errors were encountered: