haxe-react/haxe-modular

Code splitting for Haxe JavaScript projects

Shaun Holt

@ShaunHolt

Now I know where to go for help with using modular. :)

Philippe

@elsassph

Hey there @ShaunHolt

Shaun Holt

@ShaunHolt

hello @elsassph

Shaun Holt

@ShaunHolt

starting to go through your server client examples. Huge thank you for those! :)

Philippe

@elsassph

@ShaunHolt are you checking https://github.com/elsassph/zero-hx-wip ? I need to get back to that

It was very early experimentation which may have serious gaps when it comes do doing something real with it

hmm nevermind I hadn't done SSR yet

Shaun Holt

@ShaunHolt

sorry about the late response @elsassph Just saw your message.

I had checked out haxe-modular, haxe-react-redux, seems like a couple others.... didnt notice the zero-hx-wip

i'll tinker with that one, thank you.

Dmitry

@dmitry-kuzovatkin

This message was deleted

Dmitry

@dmitry-kuzovatkin

Hello @elsassph . Do we have ability right now to have next project structure with modular.
https://github.com/dmitry-kuzovatkin/testModular

Cause at the end in maincontext.js the feature__BRIDGE__ do not get resolved:

    Require.module("feature").then(function(id) {
        "feature__BRIDGE__";
        return id;
    }).then(function(_) {
        console.log("src/main/MainContext.hx:16:","FeatureContext classes Loaded");
        console.log("src/main/MainContext.hx:17:",new feature_FeatureContext(_gthis));
    });

So we still limited with
https://github.com/elsassph/haxe-modular/blob/master/doc/libraries.md#libraries-must-be-loaded-by-the-main-bundle
?

Philippe

@elsassph

Exactly, @dmitry-kuzovatkin

Dmitry

@dmitry-kuzovatkin

Ehh. Sad. i thought that maybe it's already solved somehow) Do you have plan to improve this logic, so we can load B from A and C from B?

Philippe

@elsassph

I understand it's just a test, but why do you need the loadLib method in this case?

as opposed to Bundle.load(MainContext) -> Bundle.load(SubContext)

loadLib is really to preload a bunch of shared code

Dmitry

@dmitry-kuzovatkin

i should check it. Maybe it's no reason to use loadLib now.

Dmitry

@dmitry-kuzovatkin

For Bundle.load it's not possible to set custom file name where code will be extracted?

Philippe

@elsassph

hmm not OOTB but it might be easy to solve

Dmitry

@dmitry-kuzovatkin

yeap. i will add PR on weekend for it

Philippe

@elsassph

@dmitry-kuzovatkin I think I got it working: elsassph/haxe-modular#103

Dmitry

@dmitry-kuzovatkin

Amazing. I thought that i will do it)

I'll check it tomorrow in our project

I found that Bundle.loadLib not so usefull, 'cause of this limitation which it have. Maybe will be better to improve it. Cause there's some not normal behaviour about how library split dependent classes

Philippe

@elsassph

loadLib is really meant to load something like a big framework but you still want to have a very small core code to start up.

Dmitry

@dmitry-kuzovatkin

@elsassph Hello. Sry for delay with testing. Looks like naming works, but for some reason this property is mandatory when i'm trying to compile project. Maybe it's because of haxe 4.0.0 which i'm using now. Also probably i see another issue with Bundle.lib(but i didnt fully test it). Looks like Bundle.lib(SomeClass) will also do force moving for SomeClassA, SomeClassB,SomeClassC, etc.. in external module file. I will provide more info later about it

Philippe

@elsassph

Tests run agains Haxe 3.4.7, 4.0 and 4.1 and a mandatory param would break the build. I'll double check.

Second bug sound like something that would always have been broken... Because the matching is prob done with "startsWith"

Dmitry

@dmitry-kuzovatkin

@elsassph Is it normal behaviour?:
In Main: Bundle.load(A)
In A: Bundle.load(B1) and Bundle.load(B2)
In B1 and B2: new C3()

At the end in output C3 defined in Main.js file , but not in A.js

Philippe

@elsassph

If C3 is used in B1 and B2 it will be hoisted in the common parent module

but hmm it should normally go in A

There may be other reasons for hoisting, can you repro in isolation?

Dmitry

@dmitry-kuzovatkin

https://github.com/dmitry-kuzovatkin/testModular/tree/master/src

Dmitry

@dmitry-kuzovatkin

@elsassph Do you have time to check it?

Philippe

@elsassph

Probably not immediately but maybe this evening.

Philippe

@elsassph

Ah I think I know: that's because with the custom name the modules are still considered as "libs" and libs must get all their common dependencies from the main bundle.

Dmitry

@dmitry-kuzovatkin

Is it fixable?)

And what will happen if i will do Bundle.load for two different classes with same custom name? Based on generated code and dependencies it looks ok, but is it supported functionality?) @elsassph

Cause in this case it start looks very similar with Bundle.loadLib

Philippe

@elsassph

Haha yes I'm on it

Er 2 bundles with the same custom name will break - it will be your fault :D

Dmitry

@dmitry-kuzovatkin

Damn. I'm using it right now to group some classes

Dmitry

@dmitry-kuzovatkin

But based on code library doing job correctly when i bundle feature1 and feature2 in same module file

Philippe

@elsassph

Wait a sec, are you looking to use the custom name to regroup these classes into the same bundle?

I thought you just wanted to rename the bundle file.

Because right now for you it's working because it's using under the hood the loadLib feature, which means it has the lib limitation of having to be loaded from the main bundle.

I'm fixing it by having a different mechanism to alias a bundle

Dmitry

@dmitry-kuzovatkin

No. it's not about regrouping.

But i'm trying also to solve another logic which i want to have. And it's mostly related to how we do on-demand features

Where communities thrive

People

Repo info

Activity