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
    Here is a new (probably buggy) version of the Vue GWT plugin for IntelliJ: https://drive.google.com/open?id=1RQFhLNGvQyKxJE5AviXA7W2zZneDgaF9
    Payam Meyer
    @payammeyer
    I gave up on the current one a long time ago
    Adrien Baron
    @adrienbaron
    Contains:
    • Component completion in templates (based on imports in the @Component annotation)
    • Props completion on a component for :, v-bind: (based on @Prop declarations)
    • Props navigation from HTML to Java
    @payammeyer oh :(, what issues did you have with it?
    Payam Meyer
    @payammeyer
    Honestly I don’t remember, I’ll give this a try, I’m always open to trying things.
    Adrien Baron
    @adrienbaron
    :thumbsup:
    The plugin also touch the associated Java file when you change the HTML template
    Maybe that created issues with your setup?
    (Anyway, bedtime for me!)
    Payam Meyer
    @payammeyer
    Aaah yeah I believe that’s what it was cause our gradle plugin handles that
    Adrien Baron
    @adrienbaron
    Could add a setting to disable this
    (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: