Fork me on GitHub

Fulcro-inspect 2.0.0-alpha3-SNAPSHOT has an improved version of the history visualization when you slide around in the history of the data viewer. I moved it out over the main app so the CSS there could take effect. The results mostly work. The cascading of styles isn’t ideal. Any CSS gurus want to make it better, I’d love some help 🙂 The CSS for it is here:


I'm trying to slowly port a small om-next project to Fulcro. How do I replace om/process-roots it doesn't seem available in Fulcro? I would like a gradually move to Fulcro, so having something like om/process-roots available would be nice!


Does anyone have any recommendations for digesting Fulcro for someone that's just learning Clojure and is mostly coming from Python? I have some functional programming experience coming from Elm and a tiny amount of Haskell, and no real Java experience in the last 10 years. 😅


@chancykennedy So, Fulcro itself requires that you know a bit of Clojure(script). Once you get a bit of that under your belt I’d recommend the video series on YouTube as a starting point


I’ll be adding to that over time. I think I’m up to 10 videos…they go from the very basics in a way you can follow-along with


@decoursin So, you can’t do remoting through the parser in Fulcro. Why do you think you need process-roots?


@tony.kay I don't know if I'd need it in Fulcro, I know you obviously do without it. I was requesting it to help be able to gradually convert my application to fulcro.


So, I helped write process-roots for Om Next. It’s purpose is to remove/re-add UI query “above” the thing you really want to query for. In Fulcro, we don’t need it because you never have to use the root query for remotes….in Om Next it is always from root.


Ah that's interesting, i didn't catch when skimming your docs.


How do you prevent it being from root?


Loads are explicit.


(load this :key Component) creates a query to send to the server from the Component, and merges it. No parser involved.


Ah ok thanks


I was also wondering about keys in queries that are designed to be used locally only, if I don't write the read fns, how can I prevent them from being sent in the remote queries to the server(s)?


So, to port: 1. Remote all remote from your read…new parsing read becomes your read-local for Fulcro 2. Encode your loading into calls of load and load-field 3. For keys that don’t go to server, put them in the ui namespace


> (load this :key Component) creates a query to send to the server from the Component, and merges it. No parser involved. This does seem much better, thank you for your contributions to by the way! and all the open source you've given us!


[:ui/checked? :person/name] will go as [:person/name] to server


you’re welcome! A lot of the reason I do it is because I love the model and don’t really want to program in anything else 🙂


It seems much better than anything else I've used.


(on the frontend)


hoping you’ll think that about the full stack once you get into Fulcro 😉


Yeah but it's too late for that I think, my back is already in graphql using Lacinia


oh…GraphQL is fine…I’m talking about the Fulcro load vs parser


Which I was wondering if fulcro would work well with it. I know om-next is pretty flexible, and fulcro is more opinion-nated so I was bit worried there'd be problems.


We’ll start releasing work on easier integration with GraphQL soon. Wilker’s pathom is making that story pretty nice.


Cool thanks yeah I saw that, I'm using his query->graphql fn


but I think there's probably more in his pathom that I could use, which I haven't yet.


Few of the “opinions” of Fulcro should limit flexibility in a many ways. Technically, almost everything except the database storage format are still pretty open to config.


Cool that's really nice to know


And you can always use things like DataScript as a “remote” that is stored in the browser…or customize your read-local and wire a few things up, and you can easily use other databases in tandem.


Yeah I never yet got around to reading the datascript om-next hookup, so I'm not really sure yet how that works, but i'll keep it mind.


Anyway….coming from Om Next, watch this YouTube video: It’s from when things were called “Untangled”, but it should help.


I don’t personally recommend DataScript for general use…it’s just something people know about


But do you think it's appropriate for some things?


Of course 🙂


But I think one of the things people thing they want to do with it is sync with Datomic…that I would not bother with.


Our graph syntax is already pull…it is pretty simple to make a “Meteor.js” style Datomic hook-up directly with websockets and bypass the extra overhead of syncing everything to DataScript


Nice to know, yeah I saw one of those projects like datsync or something, seemed interesting, that's interesting though


But the fundamental proposition (of syncing with DataScript) has a number of flaws…ranging from atomic operations to over-query.


I want to process an arbitrary graph query…for that to work properly I have to sync up all the entities that might be involved…but I might only need 1-2.


It means you have to now invent an API to solve that problem


@tony.kay Thanks, Tony! I'll have a go at the videos.


I’ve prototyped the meteor-like thing….it was couple 100 lines of code and simple to reason about


Yeah, it seems like a good idea on the surface, but maybe there's too many details like some of them you mentioned that would cause huge problems.


@decoursin I want to document more about that, the graphql things were an experiment, but given the increase interest I'll try to find some time to improve the code and docs around it, help to make it work better is welcome (specially because I'm not using it on prod, so real apps can help)


until then, feel free to ping me if you have any questions around it


Awesome thank you so much. Can you just briefly outline where you think it's most helpful? I'm already using query->graphql, so you can skip that. I'm only using Fulcro/om-next on the frontend would it still be useful? If someone has a graphql backend, would you recommend using your parser over the stock om-next/fulcro one? I just don't really see how it fits yet, maybe because I don't understand fulcro completely yet either. Is it more tailored to fulcro or om-next? Sorry for all the questions just answer what you'd like


@decoursin those tools are made for both front and back-end, depends on how you want to use it. for your case you can use on the client directly, I have an example app that makes a fulcro network that communicates with graphql endpoints directly, you can see it here:


this code was written before Fulcro 2.0, so some things might need change (probably just the namespaces)


using the graphql network, the graphql turns into a transparent thing, the network converts the queries on send, and revert on read (you can even use namespaced keywords, they will be stripped on send, but will be attached back automatically on the return)


Looks great thank you, I'll have a deep look at that when I get chance (which probably won't be for who knows, I'm on holidays starting tomorrow with family)


Have a wonderful holidays everyone!


thanks, you too 🙂


I am using the defrouter macro and it seems as though only the first component in the router picks up its initial state. Is this to be expected or am I doing something wrong?


@mandor2017 Chances are you’re doing something wrong.


last I checked all the demos that require this behavior work (get initial state for all branches)


show the code snippet of the router and components that have initial state ?


Thanks for the response. It's getting a bit late here in the UK to fire up the PC so I will investigate further tomorrow.


ok…the demos in fulcro (clone/follow readme) have a number of routing examples


NOTE: yesterday I mentioned wrappedInputs. I’ve changed that to rawInputs and inverted the logic so they still default to the old way for now. Will flip it in a later version, not in a release candidate 🙂


Really appreciate the effort you are putting into fulcro. Routing is the only bit so far that I have found difficult to get right.


Yeah, I’ve got some ideas around improving it, but not the time just yet 🙂