Hi!
Thank you for this detailed reply! I'm very glad that you took the time to
look into the code and you are indeed raising interesting issues.
I'll try to reply to each remarks:
=> Java to JS component translation
Indeed the Java introspection at runtime is also not my favorite thing.
Adding a $ before each property name could be a valid solution and I'm
surely considering it :).
This will also negate the need to filter out properties manually (like the
___ that is too generic), because only the "interesting" properties would
be copied over.
For the @JsProperty, sadly they still would need it (or at least a @JsType
+ public properties), as the Vue.JS template are not parsed by GWT. The
name in the template must match the ones in the JS translation of the Java
component. If GWT rename them at compile time, then you'll get for example:
{{ bob }} in your template and data: {a: "hello"} in your component.
=> Circular reference in data model.
I tried to create in pure Vue.JS a component that returns a circular
reference upon creation, and it also breaks:
https://codepen.io/anon/pen/oBXBmB
(if you remove the test.circular = test, it works again).
Also Vue doc in v1 specifically said that it needs not not contain circular
reference. In the v2 they say that you can clone the data using
JSON.stringify(JSON.parse(...));
https://github.com/vuejs/Discussion/issues/265
https://vuejs.org/v2/api/#data
Fixing the way we build the Component data to make sure to only integrate
the properties needed by the user would probably make this less of an issue.
=> Minor issues
1: Yes, for now we just wanted to get feedback, so it wasn't needed, but if
people show interest it will happen.
2: Indeed, nice catch! I'll make sure to add it to the documentation.
=> Other questions
As you saw even if the Java introspection is nice and pretty easy to do
(with naming convention), it doesn't not feel very "Java" or clean to code
with it. I was thinking about using annotations with annotations processor
to avoid having naming conventions.
For example a simple component could look like:
@Component
public class myComponent extends VueComponent {
@VueData
protected String myMessage = "Hello";
@VueMethod
protected void resetMessage() {
this.myMessage = "";
}
@VueWatch
protected void myMessage() {
// Do something
}
}
This would be much cleaner to code. Also it might be possible to
automatically bind templates, we would also gain the ability to fine tune
the component behavior by passing parameters to the @Component annotation.
My main issue with this is after doing some research, it seems that
annotation processors integrates poorly for now with GWT super dev mode.
You have to manually rereun the annotation processor after each change. I
do think the code would look nice with annotations, but if developing with
it becomes slow and cumbersome, then there is not really a point.
I wonder what you think of this idea, and if you have any experience with
annotation processor in GWT ?
Anyway, thank you very much for your feedback!
On Friday, January 6, 2017 at 7:27:29 PM UTC+1, Ivan Markov wrote:
>
> Hi there.
>
>
>> It's still a work in progress, but* we would be glad to hear what you
>> think of it.*
>>
>>
> What I think is the following: this is very neat!
>
> With the above said, I have one roadblocker and two minor issues
> (disclaimer: I'm a *complete* NB in Vue.js).
>
> The roadblocker:
> ======================
>
> You are converting the Java/GWT representation of a Vue component into the
> one Vue expects by using a runtime introspection of the VueComponent object
> from within JavaScript.
> Because of this approach, you are putting properties in data {} which are
> NOT declared as a @JsProperty in Java. You know, internal private members
> that I might have in my Vue component ending on _g$, like an EventBus
> instance or you-name-it.
> The problem with this is that the conversion fails in JSON.parse() with a
> "Converting circular structure to JSON" complaint.
>
> Given that it is not very realistic - especially in hybrid Vue/GWT Widget
> projects to have all props marked as @JsProperty, and all of these to be
> non-circular, this probably needs to be addressed.
>
> An idea: since you are anyway using naming conventions (a computed_ prefix
> for computed props, a watch_ prefix for watchers), how about applying this
> to ALL props that should end in data {} and perhaps to all methods that
> should end in methods {}?
> Perhaps you can fix it so that it processes only methods and properties
> that are starting with e.g. a single "$" or suchlike?
> NOTE: That might have the additional benefit that these methods and
> properties might not necessarily have to be marked with
> @JsMethod/JsProperty, as you - in fact - don't care about their name being
> preserved from Java to JS, as long as it starts with a "$".
>
> Another idea: you are anyway filtering out some GWT methods, like those
> starting with "$init" or with "___" (the latter might be dangerous btw as
> it is a bit too generic!), so you can just as well filter out everything
> that ends with _g$ as well, because that's the mangling suffix GWT puts on
> all props and methods which had not been exposed via @JsProperty /
> @JsMethod / @JsType annotations. Of course this relies on GWT internals and
> might break in future, but I don't think there will be a perfect, pure and
> clean solution anyway if a JS object introspection is used.
>
> Now, even if the above is addressed (and I think it should as the
> programmer has to have control what ends up in data {} and methods {}), the
> whole "return JSON.parse(JSON.stringify(data));" approach is not giving me
> a warm fuzzy feeling. Is that how Vue is supposed to work? With
> non-circular data {} only?
>
> Two minor issues:
> =========================
>
> 1. Having the project published in Maven Central soon would be nice - even
> if it is just a snapshot.
>
> 2. I was missing a "<script
> src="https://unpkg.com/vue/dist/vue.js";></script>"
> include and it took me some time to realize it. If VueGwt indeed does not
> inject the vue.js lib, this has to be at least mentioned in the GitHub
> README.md file.
>
>
> *Keep up the good work!*
>
>
--
You received this message because you are subscribed to the Google Groups "GWT
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
