Clojurians Log v2

I'm trying to have a minimal keechma app starting but i get this repl/invoke error #error {:message "System must have a :main component!", :data {:type :keechma.ui-component/error}}

Here is the code

looks to me like there is a main component !

looks like i have to add the key-value {:router :memory} or some other to the app definition

which begs the question, what are the difference between hashchange, history and memory routers

hey @carkh easiest way to generate the minimal keechma app is to run lein new keechma name-of-app

this will generate a minimal structure you need to run it

as for the routers: - hashchange - binds to hash route (after # in the URL) - history - uses pushState and history API - replaces the whole URL - memory - uses in memory atom to store the route data - we use this one mostly in the mobile / react native context

Keechma requires you to register the components in a map that you pass to the app when you start it - this map must have a component registered under the :main key

thanks @mihaelkonjevic

I would also recommend you to check https://github.com/gothinkster/clojurescript-keechma-realworld-example-app

this app is built in “keechma” way, and you can compare it with other platforms

i've been perusing many of those example apps

the minimal startup requirements seem a little bit fiddly though

for instance i had to remove the ui/system call around that map containing the main component

and the app definition had to have a :router key while i didn't see it anywhere in the example applications

see in the realworld app, there is no :router key again ><

ui/system is called internally on the map passed to the app definition

and I’m pretty sure that the :hashchange router is default

the one thing I see is that you don’t have a default route defined -> ["" {:status "all"}]

if i remove the router key, the whole page is made blank in the browser, and i need to refresh

ah let me check this default route thing

that was it !

thanks

also, you’re passing false to should-mount in app-state/start! call, this means that the app will have to be mounted manually to the dom element

that was part of my tests, it's true right now

ah, ok

another question : when trying to develop using devcards or workspaces, I need to provide a full application

so i guess that would be the occasion to use that memory router ?

yeah, you could use it in that case, but keep in mind that your urls will stop working

ok

looks like that atom is global though

personally I’m rarely using devcards because I usually like to develop with server in place, so it makes sense to test the whole app (backend and frontend)

ok i was curious about your workflow, that answers it

I did use them for pure components (that only depend on their args)

ok one last question, but that's about a place where i'm not yet arrived

i can see parallels between fulcro and keeshma

the database mainly

there are parallels between your dataloader and pathom

i have a backend that uses pathom to provide an API

with EQL as the query language

replacing graphql

do you think i'll be able to use your graphql examples to make use of that ?

or maybe do you already have some EQL loader hidden somewhere in keechma =)

I haven’t used EQL so far, so I don’t know 🙂. But, Keechma is built in a very generic way (mostly because we are using it in agency setting where we are not able to always control the backend), so you should be able to write EQL driver for that, the only thing that you need is to implement a loader that knows how to interpret params returned from the datasource’s params fn

allright that's what i thought, not a problem i think

We’ve used it successfully with REST, GraphQL, Contentful, Firebase and some other weird API backends, so I believe that EQL should be easy to implement

ok then, thanks for your kind answers, and your time

no problem, please mention me whenever you need help, because otherwise I check this channel once daily 🙂

i might do just that in the following week or two =)