Fork me on GitHub
#keechma
<
2019-05-30
>
carkh08:05:22

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}}

carkh08:05:24

Here is the code

carkh08:05:37

looks to me like there is a main component !

carkh09:05:54

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

carkh09:05:25

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

mihaelkonjevic14:05:45

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

mihaelkonjevic14:05:57

this will generate a minimal structure you need to run it

mihaelkonjevic14:05:06

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

mihaelkonjevic14:05:07

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

mihaelkonjevic14:05:08

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

carkh14:05:19

i've been perusing many of those example apps

carkh14:05:21

the minimal startup requirements seem a little bit fiddly though

carkh14:05:02

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

carkh14:05:38

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

carkh15:05:15

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

mihaelkonjevic15:05:25

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

mihaelkonjevic15:05:40

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

mihaelkonjevic15:05:02

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

carkh15:05:13

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

carkh15:05:20

ah let me check this default route thing

carkh15:05:07

that was it !

mihaelkonjevic15:05:19

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

carkh15:05:42

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

carkh15:05:07

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

carkh15:05:20

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

mihaelkonjevic15:05:56

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

carkh15:05:41

looks like that atom is global though

mihaelkonjevic15:05:44

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)

carkh15:05:14

ok i was curious about your workflow, that answers it

mihaelkonjevic15:05:15

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

carkh15:05:13

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

carkh15:05:35

i can see parallels between fulcro and keeshma

carkh15:05:51

the database mainly

carkh15:05:03

there are parallels between your dataloader and pathom

carkh15:05:24

i have a backend that uses pathom to provide an API

carkh15:05:45

with EQL as the query language

carkh15:05:49

replacing graphql

carkh15:05:14

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

carkh15:05:12

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

mihaelkonjevic15:05:12

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

carkh15:05:43

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

mihaelkonjevic15:05:56

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

carkh15:05:25

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

mihaelkonjevic15:05:47

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

carkh15:05:08

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