Hi!
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.
On Friday, January 6, 2017 at 7:27:29 PM UTC+1, Ivan Markov wrote:
-- 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:
(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(...));
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:
@Componentpublic 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 google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment