Re: Best Practice for JSON object recreation on client

"domain object" vs "message payload"; Yes, this is the point. We came from RequestFactory which works quite good with "domain object" models, we use one model for each type, this model is the same in the server and the client, and all views use the same model.

So, responding to the 'JSON object recreation in the client'; JsInterop makes trivial Object recreation, you map your messages in a very explicit and clean manner having almost zero overhead, but you should take care of this "domain object" vs "message payload" model strategy. JsInterop doesn't work well with "domain object" models (so questions like how can you return a Set or a Map are currently hard to answer, and makes no much sense in the "message payload" side), but it will work much better with "message payloads". We are getting really good result using plain classes without methods. But it's important to think on terms of "message payloads", you should try to avoid fancy things, using only primitives (plus Boolean, Double and String), arrays or other @JsType models. We end up with lot of services like this. This models frequently do not need any special annotation, but are so simple that most JSON encoder works correctly (Jackson, gson, moshi...) and obviously JsInterop.

@AutoRestGwt
@Path(RESOURCE_TOOLS)
@Produces(MediaType.APPLICATION_JSON) @Consumes(MediaType.APPLICATION_JSON)
public interface ToolsRestService {

    @GET @Path("build")
    Single<BuildInfo> getBuildInfo();

    @JsType(namespace = GLOBAL, name = "Object", isNative = true)
    class BuildInfo {
        public int buildDate;
        public String version;
        public String commitId;
        public String javaVersion;
    }

    @GET @Path("system")
    Single<SystemInfo> getSystemInfo();

    @JsType(namespace = GLOBAL, name = "Object", isNative = true)
    class SystemInfo {
        public double startupTime;
        public double totalMemory;
        public double freeMemory;
        public double usedMemory;
    }
}

I like to think of this classes as something like JSON (JavaScript Object Notation) but in Java and to define the scheme instead of the object itself so JOSN (Java Object Scheme Notation), i.e. a subset of Java just to define objects schemes. 

On Saturday, August 20, 2016 at 12:54:24 AM UTC+2, Thomas Broyer wrote:

I think the crux is thinking in terms of messages (payloads) rather than "domain objects". This applies to DTOs vs domain objects too, with RPC or RequestFactory or whatever.

--
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.