What had been the care previously? Were you calling the chrome methods in
some way other than through JSNI? Java methods can't call raw JavaScript
without JSNI (or JsInterop, which didn't exist in GWT 2.6).
Otherwise I'm not sure what you changed it _from_ to get to the psuedocode
in your
So it appears that this is caused by JSNI methods somehow being morphed
when the GWT app is compiled. I don't know how, but I do know that calls
to Chrome proprietary APIs aren't working correctly. I modified my code to
do the following:
Java method calls JSNI method
JSNI method calls raw
So it appears that this is caused by JSNI methods somehow being morphed
when the GWT app is compiled. I don't know how, but I do know that calls
to Chrome proprietary APIs aren't working correctly. I modified my code to
do the following:
Java method calls JSNI method
JSNI method calls raw
So it appears that this is caused by JSNI methods somehow being morphed
when the GWT app is compiled. I don't know how, but I do know that calls
to Chrome proprietary APIs aren't working correctly. I modified my code to
do the following:
Java method calls JSNI method
JSNI method calls raw
Yes, I think you would need a good immutable collection library to make
Redux work well from Java. In our application we are just using React
State. This works fine because we are replacing relatively small isolated
parts of our application currently (1 or 2 connected screens at the most).
Side question: I can imagine that the lack of object spread probably makes
Redux a bit annoying to use from Java. Yet, if you are not using neither
Redux nor MobX, how are you managing your state?
On Monday, May 1, 2017 at 3:48:51 PM UTC+3, Paul Stockley wrote:
>
> I agree both Redux and MobX
I agree both Redux and MobX are both pretty stable. The decision was more a
reflection on the current state of the GTWReact projects. I would say both
are really proof of concepts at this stage. Redux in particular would
really need interfaces building to the common middleware to be really
