Here's where I find local state useful and I am curious how advocates of
centralized state handle it:
A view component that allows editing. For example, click on the text and it
changes to an input element. To me that is local state: I'm in reading mode.
Now I'm in editing mode. In my own app,
I would assume you're right that very few are transient. At least with
Mikes approach, you can log the error, notify the user and continue working
from a clean state (but I assume if the user does the same thing again the
error would happen again - that is, they can continue doing other things).
On Saturday, May 16, 2015 at 1:03:49 AM UTC+10, Colin Yates wrote:
Data for the win.
I remember in the olden days when AOP reared its head and people were
talking about retrying updates against stale data/exceptions. I was
always/still am a bit cynical because I just don't see that many
For me, I can't use the 'snapshot app-db and discard' as the app-db is
synchronised with the server periodically. As you mention, I have a
number of roots in my app, one for 'ui' entries and one for 'views'
which are populated by the server, even if I want to discard the 'ui'
root I really don't
On Saturday, May 16, 2015 at 12:36:02 AM UTC+10, Colin Yates wrote:
For me, I can't use the 'snapshot app-db and discard' as the app-db is
synchronised with the server periodically. As you mention, I have a
number of roots in my app, one for 'ui' entries and one for 'views'
which are
Am I correct that what you want is a temporary scratchpad where you make
edits which can then be committed to the global state, or discarded, based
on user action?
There are two ways that I've used to do this:
The first is to take a snapshot of the state before making changes (perhaps
using
Data for the win.
I remember in the olden days when AOP reared its head and people were
talking about retrying updates against stale data/exceptions. I was
always/still am a bit cynical because I just don't see that many
exceptions where the exception is transient and the second attempt
would
Oh, I forgot to mention one difference I have occasionally seen with IBM
JDK 1.8.0: It occasionally core dumps in the IBM JVM during JIT
compilation. It is hit-and-miss, maybe one out of 5 times or so when
running 'mvn clean test'. I have made no attempt to determine what the
cause is.
Andy
On
Testing done on 1.7.0-beta3 and results:
Ran 'mvn clean ; mvn test' on a few OS/JDK combos that are not tested as
often. Reason: there have been (or still are) build or test failures with
some of them.
Windows 7 Enterprise SP1 + Oracle JDK 1.7.0_72: 3/3 times ok
Ubuntu 14.04.2 LTS + IBM JDK
For those interested in delving into React Native with ClojureScript, I took a
stab at documenting how you get off the ground with a new project:
https://github.com/omcljs/ambly/wiki/ClojureScript-React-Native-Quick-Start
--
Note that posts from new members are moderated - please be patient
On Friday, May 15, 2015 at 12:25:45 AM UTC-4, Mike Fikes wrote:
With some relatively minor tweaks to its Om binding, it is possible to run
Luke VanderHart's Quantum Tic Tac Toe React web app natively on iOS using
React Native.
For those interested, the port is in
11 matches
Mail list logo
