by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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
    @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