Haxe, react-native and component instance creation - recommended approach?

[der Raab]

Hi everybody, we're starting to dive into creating react-native apps using our existing codebase and now I ran into the different approach how and when actual component instances are created.

I've read the docs regarding elements, components and instances:

https://facebook.github.io/react/blog/2015/12/18/react-components-elements-and-instances.html

https://facebook.github.io/react/blog/2014/10/14/introducing-react-elements.html

https://facebook.github.io/react/blog/2015/12/18/react-components-elements-and-instances.html

So I think I have a good understanding why porting our existing approach is not straight forward. So this is the "problem" demonstrated as an abstract example:

Usually we use factories for instance creation on an abstract layer und implement views only based on an unified interface. So this is an example interface for an view component:

interface IViewComponent {

    public function setValue( value : String ) : Void;
}

This is my react native component (at least I thought it is necessary to extend ReactComponent?):

class ViewComponent extends ReactComponent implements IViewComponent {

    private var _value : String = "";

    public function new() {
        super();
    }

    public function setValue( value : String ) : Void {
        _value = value;
    }

    override public function render()
    {
        var value : String = _value;
        return jsx('<View><Text>{value}</Text></View>');
    }
}

This is a factory I tried to create for creating a react native component:

class ViewComponentFactory {
    public static function create( value : String ) : IViewComponent {

        // Here we usually create an instance - but react native creates only an element :/
        var viewComponent : IViewComponent = cast jsx( '<ViewComponent/>' );
            viewComponent.setValue( value );

        return viewComponent;
    }
}

And this is how I tried to embed the component within an container:

class Container extends ReactComponent {
    public function new() {
        super();
    }

    override public function render()
    {
        var viewComponent : IViewComponent = ViewComponentFactory.create( "VALUE" );
        return jsx('<View>{viewComponent}</View>');
    }
}

If you're already familiar with react you will understand, that in my

ViewComponentFactory

the call to

viewComponent.setValue()

will fail with "viewComponent.setValue is not a function", since the value of viewComponent isn't actually an instance of my

ViewComponent

class but the ELEMENT that defines the ViewComponent, which will be generated later in reacts rendering logic.

So now I wonder what options I have to work with the same factory APIs as always?

Is there an undocumented way to create the instance immediately? Or an react native equivalent to ReactDOM.render()?

I think I might work with the ref-callback and wrap some calls into asynchronous handling, but I'ld love to fix this behaviour (at least within my factories).

Did you run into that - what would you suggest?

[Philippe Elsass]

Hello,

Unfortunately you won't be able to use the same factory principe.

You typically must provide all the data as props - you can use a factory like that:

static function create(value) {

    return jsx('<MyComp value=$value/>');

}

You can do something generic as well:

static function factory(CompClass:Dynamic, props:Dynamic) {

    return jsx('<CompClass {...props}/>');

}

To update a view, you basically should:

- change the state of the parent container using setState,

- which in turn will trigger a local render,

- where you can call your component factory providing the new values.

Some more info and Haxe-related links:

https://www.slideshare.net/PhilippeElsass/haxe-react-architecture-and-workflow

Philippe

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

Philippe

[der Raab]

Thanks - and thanks for the slides!

[der Raab]

Well, I think I'll use the ref callback then and organize my workflow around that. :/ Allright then.

class ViewComponentFactory {

    public static function create( value : String ) : IViewComponent {

        var ref = function( viewComponent : IViewComponent ) {

            viewComponent.setValue( value );
        }

        return cast jsx( '<ViewComponent ref={ref}/>' );
    }
}

[Andrzej Smolinski]

Hi Markus,
I'm not an react expert but ...

you should search for "react smart vs dumb components", "react stateless functional components" and (most common?) "HOC pattern" in classic js-react, using props ... (and mapping state to props (redux)) ... HOC can contain another HOC [that can contain HOC] ... like chaining decorators - are composable

however HOC can be difficult in haxe: https://github.com/massiveinteractive/haxe-react/issues/18


I think it can be directly compared to MovieClips - it looks like trying to call instance.gotoAndPlay(x) instead of setting some value whitch can be 'consumed' by clip's logic when it's needed, just set value and let them decide what to do with it. Replace clip, change depth, structure ... it can still work not driven directly - data-driven instead  .... >>>Inversion of control is sometimes facetiously referred to as the "Hollywood Principle: Don't call us, we'll call you"<<<

Andrew

PS. I tried to contact you, didn't got my e-mails?

[Philippe Elsass]

Well this ref approach works but it's really awkward.

I really suggest to understand and embrace the way React was designed to work (props, state, HOCs) otherwise you'll really end up having issues - if you want you can hide props and state reads in getters.

BTW HOCs is just about creating a wrapper component: this component receives props, can change its state, and render another component with updated props. 

What is difficult about HOCs to reproduce in Haxe is the practice of shadowing/replacing the real class with a wrapped version of the class. I wouldn't say that this is a very practice anyway.