uhm, I suppose the easiest way to deal with it is by bundling a CDN version of react with the build using https://github.com/back2dos/embed-js
(and setting
-D react_global)
Applying idea of https://github.com/MVCoconut/coconut.data#injecting-services (modularize models to reduce dependencies).
Imagine a Model with
Called from travix or for unit test, this Model will be given a dummy function like
But when compiled in an App, the Model would receive a tink_web proxy, like
While this
Any idea? It is not a big problem in itself, but I am trying to develop good habits and this is why I ask for the best way
Imagine a Model with
@:constant var server : { function foo():Promise<String>; }.Called from travix or for unit test, this Model will be given a dummy function like
()->"Foo".But when compiled in an App, the Model would receive a tink_web proxy, like
tink.web.proxy.Remote<Something>.While this
Something has a function foo, it won't unite (because there seem to be subtleties in the macro), giving this error: tink.web.proxy.Remote1 should be { foo : () -> tink.Promise<String> }.Any idea? It is not a big problem in itself, but I am trying to develop good habits and this is why I ask for the best way
because String is converted to
IncomingResponse on client side
or even
{foo: () -> remote.foo()}?
Better I type here than add garbage to MVCoconut/coconut.ui#92. So after updating +tink state (1.0.0-beta.3) and core (2.0.2), the JS fails at the last line with process:
var wasUpdating = tink_state_Observable.isUpdating;
tink_state_Observable.isUpdating = true;
return tink_core_TypedError.tryFinally(function() {
var hrtime = process.hrtime();process is not defined
that may be js.Node.process but why is it undefined?
:eyes: forget it. if I try to run it from a browser of course
process is not defined...
A question on patterns for async data source, which one is better?
class OverviewPage extends View {
@:attr var data1:Promised<Data1>;
@:attr var getData2:()->Promise<Data2>;
@:loaded var data2:Data2 = getData2();
@:attr var getData3:()->Promise<Data3>;
@:attr var data4:Model4;
function render() '
<Widget1 data=${data1} />
<Widget2 data=${data2} />
<Widget3 getData=${getData3} />
<Widget4 data=${data4} />
';
}
class Model4 implements Model {
@:attr var getData:()->Promise<Data4>;
@:loaded var data:Data4 = getData();
}
but you get the idea
although to create a model only for the sake of having one piece of loaded data is a bit overkill ^^
now whenever I wanted to test my view isolated I need to prepare a remote
I think I prefer #1 in most of the cases but it is not very ergonomic when it comes to optional attribute
and I even proposed to add
@:promised var data:Data1 as a shorthand of #1
one option is to make a
@:genericBuild class Like<T> {} that takes an interface/class and returns a structure corresponding to it
then you can go
@:constant var services:Like<Remote<Api>> and you can stick in a remote, but during tests just an anonymous object that returns what you want it to
or you can have an interface for your model and then one implementation is build on remotes and another is just a mock that is easy to set up for tests
I have
And in the
But the second argument of
ModalWindow extends View.And in the
App class, static function modal(modal:ModalWindow) { ... ; Renderer.mount( div, modal); }.But the second argument of
Rendered.mount has to be RenderedResult; so what is the recommended way to render a view? (render() is private, so that's not it right?)
How feasible is it to use something like antd (https://ant.design) with coconut or just haxe-react? I'm having issues making haxe externs for antd's typescript but also wondering if there will be other snags I'd hit trying to use its components, preferably in a coconut-ui-based app.
class Team implements coconut.data.Model {
@:editable var color : String;
}
class World implements coconut.data.Model {
@:editable var colors : List<String> = List.fromArray(['red', 'green']);
@:computed var teams : List<Team> = colors.map( k -> new Team({color:k}) );
}colors will be edited, I think the objects in teams will be entirely rebuit. But when each team is complex enough, with @:loaded and what not, it is not very good. I am trying to find a way for them to persist but keeping @:computed if possible. Or is there a better approach
in
@:computed you can also access the last value as $last which is an Option (because on the first computation it is None) ... it's a little less straightforward, but since the previous value is discarded after the computation, you need not worry about keeping too many stale values around
class V extends View {
@:state var num : Int = 0;
@:attr var setVal : Int->Void = (n:Int) -> num = n;
function render() <>
<input type="number" defaultValue={Std.string(num)} />
<button onclick={setVal(24)} value="24" />
<button onclick={setVal(37)} value="37" />
</>;
}_0__ [ 24 ] [ 37 ], however on the react-dom backend (only), clicking the buttons 24 and 37 won't change the input. I think this is a problem that can not be fixed for now and instead it has to be worked around, but does anybody understands what's wrong in the first place?
if I encapsulate with a ParentView and even a Model (
V.num in this case becomes an @:attr and setVal loses its default callback) I have the same problem. There has to be a secrete recipe!
coconut.vdom set defaultValue and value directly (i.e. the properties of the DOM API), whereas react has some odd opinionated way to apply these differently ... defaultValue corresponds to thevalue attribute which provides the initial value for the value property ... it is also the value that's assumed by the value property if the parent form is reset ... so long as the user hasn't entered a value on their own (or value was set via JavaScript), then altering defaultValue will alter the input's value