This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # aws-lambda (14)
- # babashka (4)
- # beginners (66)
- # clojure (113)
- # clojure-spec (9)
- # clojure-uk (7)
- # clojurescript (24)
- # data-science (12)
- # datomic (45)
- # docker (2)
- # emacs (1)
- # fulcro (48)
- # jobs-discuss (22)
- # kaocha (7)
- # keechma (3)
- # luminus (7)
- # off-topic (7)
- # re-frame (6)
- # shadow-cljs (43)
- # spacemacs (18)
- # tools-deps (2)
- # vim (1)
- # vscode (2)
- # yada (11)
Attempting to get the fulcro-native-template running. It works fine in the browser and in the simulator, but I get the following error on my iphone:
Transit decode failed! SyntaxError: JSON Parse error: Unexpected identifier "Could" . The api server has no log of any connection attempt. Are there any known issues with running on an actual device?
Almost certain an inability to connect…I’m guessing the result of that message is some part of a network error string.
Did you remember to rewrite the host/port connection parameters in the code when they are using a device? You have to figure out the real IP to use, of course.
Unrelated question, but what are the options for developing native apps with fulcro for iPhone? Do you steel need macOS and Xcode?
If you use Expo, you don’t need macOS. You could do all your development while testing on an actual iOS device that is connected. Now, it is more convenient to have the emulator available - when I’m laying out a new screen, I’ll typically run 3 emulators at once using different iPhones (small, medium, large) to make sure the layout adjusts correctly across screen sizes. But it’s not technically necessary.
The instructions there assume you are using an emulator, so the part where it says ‘Go to the Expo terminal window and press 'i'’ Just use the command for running on a connected device instead (I don’t recall the shortcut because I have a different method for running on devices, but there should be a menu in the console where you ran expo, or you can use the expo tools web page that opens up).
Might as well share that other method, which lets you connect over WiFi instead of having to plug your device in through a USB cable. To do that, make sure your shadow-cljs build is running, and run ‘expo start’ as usual. Then on your device, download the Expo client from the App Store. Run the expo client and on the main screen, it will say something like ‘<app name> running on <computer name>’ under the ‘recently in development’ section. Click on your app and it will load and run.
Sometimes from the UI it is necessary to see if
foo already exists on the server, and you can do so like this:
(and foo (-> foo :db/id tempid/tempid? not)). That's where you have
:db/id s on the client and are creating tempid-s. But what about where you use uuid-s instead? I could think of using a boolean attribute on the client (possibly with a :ui/ prefix). But is there a standard idiom for this?
Why can’t you use the same idiom? tempids can be uuids, so you could use your own uuid key across all entities like :my/uuid or per namespace like ::my.type/uuid and still use the (not tempid/tempid?) form? Am I missing something?
That’s a salient question. Working on RAD I want to support both, but I really believe tempids make the most sense for new things independent of your server-side ID type. But similar to what @U07KXN95L said: tempids contain uuids, so server tempid rewrite can just be “unwrap”. The rewrite will still happen on return (return a tempid map from tempid to unwrapped tempid), but this carries this important bit of information in the client about which things are new (unsaved).
That’s basically what I do throughout my app, except I don’t just unwrap the tempid. I use Datomic and all my entities that don’t have a natural key have UUIDs, but I want to use the squid generated by Datomic for performance reasons, so that’s what I map to the tempid.
didn’t they say something about not having to worry about that some time ago, though?
but the main docs still recommend them in some cases, but not specifically for Datomic itself https://docs.datomic.com/on-prem/identity.html#org94c3f66
> If the ability to discover the time that a squuid was created leaks sensitive information, then squuids may not be appropriate. Datomic’s indexes are optimized to gracefully handle all UUIDs, so Squuids are not strictly necessary. However, you should still prefer Squuids if your ids may ever be indexed in other, non-Datomic systems.
Hmm, I don’t think leaking the creation time is a big deal in my app, but I’ll have to think about that some more. In general, I’ve found the fact that squids increase sequentially to be useful for debugging (though I would never make app logic depend on that). Like if I want to inspect the latest item added to a large list - sifting through dozens of UUIDs in Fulcro Inspect isn’t fun, but I can go to the repl and grab that part of app state, sort by id and quickly find what I’m looking for.
working on getting the websockets support rewritten to sente away from socket-io. Almost polished
We have a port of sente we’re keeping for a product for that reason…so I think we’ve got it
Looking back, I don’t know how I managed the first 8-9 months of this project without inspect. It has saved me so much time since you got the electron version working. Thanks again!
welcome. I’m looking forward to this new version….the db tab is just too slow for general use IMO. It tries to do too much all at once. I’m leaving it there, but the new db-explorer tab will be much more useful in regular cases I think.
BTW, if all goes well we should be in Test Flight sometime next week! I’ll send you an invite when available.
FYI, I use regular Sente and set the env variable SENTE_ELIDE_JS_REQUIRE=true Looks like that is fixing the same issue as your fork of Sente, no?
@U0CKQ19AQ wow, squuids being not necessary is a revelation, thanks. btw we’ve also released into beta this week, can’t imagine how we could possibly handle that much of business logic with anything else. great to see Fulcro’s getting traction! the app is in Russian only for now, and there’re a lot of rough edges, but users seem to be happy :)
though I have to say: using an env var is kind of a pain, since if you have many builds it affects them all
we have node + native + web all in one shadow-cljs build system…run one server, and you cannot have mulitple versions of the env var
Just re-hijacking this thread. I didn't realise I could still create entity ids on the client as tempid-s. So I'll just change the code to
Thanks @U07KXN95L and @U0CKQ19AQ. Should make this refactor easier than I thought it would be.
(and foo (-> foo ::foo/id tempid/tempid? not))