Closed thorlucas closed 2 years ago
Is it necessary in that situation to add it to the setter methods as well?
I believe it only needs to be implemented on any methods that must be available from JavaScript.
On the surface this sounds possible, but I have some concerns around how it will play with other features:
&mut self
setters?#[builder(setter(into))]
setters, which have type parameters in their arguments?each
setters?It's important to me that new features largely interoperate with other existing features; documentation of proc-macros is still difficult, so having too many edge cases would make the crate very hard to use.
I currently have other time commitments that prevent me from working on this, but if someone else wants to take on the implementation and testing I'll happily review the results.
I don't see good answers to the above questions on the horizon, and don't think derive_builder
can take on the test burden of making this fully supported.
That said, I also don't see as many Builder
-style APIs in JS; much more often, I see APIs that take an Options
plain JS object and use that to initialize the class. I might suggest using the builder for construction in Rust, but then having another function that is #[wasm_bindgen]
that takes a JsObject
and initializes your type from that.
One could even make a proc-macro for it, e.g. #[derive(OptionsConstructor)]
- that would be able to handle the parsing of the object and mapping of its properties to fields on the target struct.
This is now actually possible using #[builder_setter_attr(wasm_bindgen)]
, but you'll have to be careful not to use features that break WASM (e.g. generics, &mut self
, etc.) - derive_builder
will not do any testing of compatibility between the options you've chosen for your builder and additional attributes you choose to apply.
Hi,
Is it possible to add this macro to the builder? Maybe just behind a feature flag.
Thanks,