-
Notifications
You must be signed in to change notification settings - Fork 17
General design
-
Component - a type and corresponding method set definition; this is equivalent to a React component, e.g.
HelloMessageDef -
Element - an instance of a component's pointer type, e.g.
*HelloMessageDef
The general approach being proposed is that components will be declared by the developer, followed by some element of code generation to do the grunt work of helper-method generation etc. More details to follow
See the wiki for code generator design
What naming convention should we use for:
- packages
- types (components, props and state)
- functions (e.g. to create elements from components)
when it comes to defining GopherJS React components?
We need to consider intrinsic components and user-defined components (the answers may be different)
// ********
// Option 1
// github.com/myitcv/gopherjs/react
package react
type ADef struct { ... } // the <a ...> component
type AProps struct { ... } // props for <a ...> component
func A(...) *ADef { ... } // create an <a ...> element
// github.com/myitcv/gopherjs/react/examples/hellomessage
package hellomessageWhether to automatically PureRender for components whose corresponding state and props values are comparable
Assuming there is some conclusion to https://github.com/gopherjs/gopherjs/issues/236, we can do away with the existing helper-functions, e.g. PProps, rename the types, e.g. PPropsDef -> PProps, and use the types directly:
x := P(&PProps{ClassName: "wide"}, ...)For usability reasons, this however means we need to move away from the embedding of, for example *react.BasicHTMLElement, to explicit definition of fields:
type PProps struct {
o *js.Object
Id string `js:"id"`
Key string `js:"key"`
ClassName string `js:"className"`
// ...
}This will clearly require some sort of code generation based on some higher-order definition of the props for each component.
Follow up with neelance about a different API for the gopherjs/react package that unifies state and props