by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Adrien Baron
    @adrienbaron
    (PR welcome if people want to look into that, latest changes are on develop)
    (On the vue-GWT-IntelliJ-plugin repo in our Github org)
    Matt Davis
    @mdavis95
    Yeah I think it was the touching the file. Our Gradle plugin handles that now
    I agree I like the camel case. Sorry I was late to the game
    Adrien Baron
    @adrienbaron
    @mdavis no worries ;). For the camecase VS kebab I’ll try and make the prop recognition/navigation work with both, and completion will favour camel case for props for now. Having a setting to select which one you want the completion to suggest would be the best ;)
    Matt Davis
    @mdavis95
    Looks like nashorn is being removed in Java 15
    Just in time
    Adrien Baron
    @adrienbaron
    Cool 👍! I mean Vue GWT already didn’t build with JDK13 for some reason (was complaining about Nashorn), so maybe want included in default OpenJDK distribution of JDK13?
    Candide Kemmler
    @ckemmler
    In our app, we have lots of modal components. We used to add them to the top "App" component and to make them visible by toggling a showingboolean Prop, but at this point, this all looks rather silly: we would rather like to be able to create Modals "out of thin air" and just adding them to the App component dynamically. But is that possible?
    Payam Meyer
    @payammeyer

    We do it this way for a simple confirm type dialog (using vuetify):
    SimpleDialogComponent.html
    `

    <v-dialog v-model="dialog" persistent width="400">
    <v-card>
    <v-card-title class="subtitle-1 primary white--text" primary-title >
    {{title}}
    </v-card-title>
    <v-card-text class="mt-2">{{message}}</v-card-text>
    <v-card-actions>
    <v-spacer></v-spacer>
    <v-btn text color="error" @click="dialog = false">No</v-btn>
    <v-btn depressed color="success" @click="handleYes">Yes</v-btn>
    </v-card-actions>
    </v-card>
    </v-dialog>
    `

    SimpleDialogComponent.java
    `
    @Component
    public class SimpleConfirmDialogComponent implements IsVueComponent {

    @Data
    boolean dialog;
    
    @JsMethod
    public void handleYes() {
        // to be overriden
    }
    
    @Computed
    public String getTitle() {
        return "To be overriden";
    }
    
    @Computed
    public String getMessage() {
        return "To be overriden";
    }
    
    public void showDialog() {
        dialog = true;
    }

    }
    `

    and then the java class can be extended and used for different purposes, the sub classes need: @Component(hasTemplate = false)

    I don't know why Gitter is being stupid with the formatter but you get the idea
    Colin Alworth
    @niloc132
    three ticks to format a code block, or indenting - you did one tick so it didnt format until it got to the indented content
    Candide Kemmler
    @ckemmler
    That's cool, but I'm not sure it's going to help us. To be more specific, that's what we end up having:
        <modal-dialog :title="msg.Tags()" ref="tags-modal">
            <tags></tags>
        </modal-dialog>
    
        <modal-dialog :closeOnly="true" :title="msg.Move()" class="move-dialog" ref="move-modal">
            <mailboxes @new-parent-folder-selection="parentFolderSelection" key="move-messages-mailboxes"
                       mode="MOVE_MESSAGES" slot-scope="{ ModalDialogContentProps contentProps }"
                       v-if="contentProps.isReady"></mailboxes>
        </modal-dialog>
    
        <modal-dialog :title="msg.Templates()" class="templates-dialog" ref="templates-modal">
            <templates slot-scope="{ ModalDialogContentProps contentProps }"></templates>
        </modal-dialog>
    
        <modal-dialog :defaultActionLabel="msg.Create()" :title="msg.Create()"
                      class="new-folder-dialog" ref="new-folder-modal">
            <new-folder></new-folder>
        </modal-dialog>
    
        <modal-dialog :defaultActionLabel="msg.Rename()" :title="msg.Rename()"
                      class="rename-folder-dialog" ref="rename-folder-modal">
            <rename-folder></rename-folder>
        </modal-dialog>
    
        <modal-dialog :defaultActionLabel="msg.Save()" :title="msg.Tags()"
                      class="new-tag-dialog" ref="new-tag-modal">
            <new-tag></new-tag>
        </modal-dialog>
    That's all inside of some top-level component. What we are nervous about is that all those modals seem to be preemptively initialized by Vue, and will end up taking a huge amount of memory, even if they are not going to be used. What we would like to do is instantiate those modals on demand.
    Adrien Baron
    @adrienbaron
    @ckemmler you'll have to have your modals somewhere in a template already, however you could manage to not render them in advance
    Hum actually now that I'm thinking more about it you might even manage not to have them in the template
    Candide Kemmler
    @ckemmler
    we don't render them by using a showingflag, but we notice that all the lifecycle methods are being called nonetheless
    Adrien Baron
    @adrienbaron
    If they have a v-if="showing" then it shouldn't call those methods at all
    I was thinking of another solution though
    So let's say you have some kind of ModalManager component at the root of your App
    It could register itself in a dependency you inject or some other mechanism
    Then when you would like to show a modal you'd call something like myProvider.modalManager.showModal(title, modalClass, ...)
    Candide Kemmler
    @ckemmler
    Sorry, I don't get it, can you be somewhat more explicit :-/?
    Adrien Baron
    @adrienbaron
    Sorry, it's a bit hard with text :D
    Candide Kemmler
    @ckemmler
    But how do I specify their "inner" component, if not in a template?
    like, above, the <new-tag> compoent
    Adrien Baron
    @adrienbaron
    You can use the is attribute: https://vuejs.org/v2/api/#is
    That let you pass the name of a component and it uses it to render
    Candide Kemmler
    @ckemmler
    interesting... I'll think harder ;-)
    Adrien Baron
    @adrienbaron

    So for example:

    <span is="new-tag-dialog" />

    is the same as:

    <new-tag-dialog />
    Candide Kemmler
    @ckemmler
    can the is attribute be dynamic?
    Adrien Baron
    @adrienbaron
    Cool thing is you can also bind it:
    <span :is="modalType" />
    Yep
    Candide Kemmler
    @ckemmler
    Awesome!
    Thanks @adrienbaron !
    Adrien Baron
    @adrienbaron
    Only thing is the component needs to be registered globally
    Using Vue.component("my-component", MyComponent.class)
    So with that you should be able to have some kind of modal manager where you can stack modal definitions and it just loop through it and renders them :thumbsup:
    Payam Meyer
    @payammeyer

    @adrienbaron I've recently noticed that I'm getting the following warning:

    vue.esm.js:629 [Vue warn]: Invalid prop: type check failed for prop "step". Expected Number with value 2, got String with value "2"

    for router query properties that are non-string. The current implementation of vuegwt router forces us to pass in Strings. Is that something you could fix? Or am I doing something wrong?

    I can get around it, but I think it would be nice if location took a query map of JsPropertyMap<Object> if that's possible.
    Adrien Baron
    @adrienbaron
    @payammeyer Hum, I think router query property are always strings, they get set on the query from the browser so they always get passed to you as String
    It probably works right now if you put a number, because in JS the string "2" will get turned to a number if you try to do an operation with it and a Number
    You can check this is right by trying to set the query, and console.log your query prop, you'll probably see the String and not a number
    Payam Meyer
    @payammeyer
    ok so I should be handling it after the property is passed in, that's ok, thanks.
    Adrien Baron
    @adrienbaron
    (for example set the query in the URL yourself and reload the page, i'm pretty sure you'll get a string in your query prop :))
    yes :)
    You should parse the string yourself :)
    Payam Meyer
    @payammeyer
    I'm fairly sure though I didn't see the warning before, it popped up recently through version upgrades, that's what got me wondering.
    Adrien Baron
    @adrienbaron
    oh right, this is because we added a behavior for @Prop to have automatic type checking