precept

Preception!
alex-dixon 2018-03-12T20:19:12.000585Z

Hey @amarjeet. Let me take a look

1šŸ‘
alex-dixon 2018-03-12T20:24:12.000197Z

First thing that comes to mind is perhaps the user is already logged in? e.g. :loggedIn fact already exists

alex-dixon 2018-03-12T20:24:32.000610Z

Looks like the view might not permit login when loggedIn is true thoughā€¦

amarjeet 2018-03-12T20:24:54.000320Z

no, :user/loggedIn fact is getting inserted for the first time

1šŸ‘
alex-dixon 2018-03-12T20:29:35.000480Z

Can you clarify what data doesnā€™t exist and how youā€™re able to detect this?

alex-dixon 2018-03-12T20:30:43.000112Z

Iā€™m thinking youā€™re looking for this:

{:db/id (:id %)
                           :user/name (:name %)
                           :user/email (:email %)
                           :user/membershipId (:membershipId %)
                           :user/loggedIn true})
but I donā€™t see rules or subscrtptions that deal with these fields apart from authentication-successful which matches on :user/loggedIn

alex-dixon 2018-03-12T20:31:09.000680Z

At a high level things should work as you described and I canā€™t see anything that would cause them not to

amarjeet 2018-03-12T20:31:23.000020Z

I assumed it because when I fire the authentication-successful rule without [[?user :user/loggedIn true]] , the `:home-page gets rendered

amarjeet 2018-03-12T20:31:51.000357Z

@amarjeet uploaded a file: https://clojurians.slack.com/files/U623NFZ17/F9NL10KK4/-.clj

amarjeet 2018-03-12T20:32:19.000020Z

I am using these subs, also, the API is working - have checked them separetly

alex-dixon 2018-03-12T20:33:33.000510Z

Hm. Well, a rule shouldnā€™t fire unless all its conditions are true. I might try changing [[?user :user/loggedIn true]] to

[?the-fact <- [?user :user/loggedIn true]]
and logging ?the-fact if you havenā€™t

amarjeet 2018-03-12T20:33:58.000080Z

let me try this

alex-dixon 2018-03-12T20:33:59.000474Z

Nice. This all looks great

alex-dixon 2018-03-12T20:37:13.000003Z

Iā€™d consider using insert! instead of insert-unconditional! wherever you can. Itā€™s not clear whether youā€™re retracting facts elsewhere though (in which case insert-unconditional! is your friend)

alex-dixon 2018-03-12T20:38:13.000274Z

Iā€™m not confident thatā€™s related to the problem youā€™re experiencing, just something I noticed

amarjeet 2018-03-12T20:40:51.000279Z

So, its really strange that the rule with [[?user :user/loggedIn true]] alone is getting fired. But, its not getting fired when other conditions are put in - ex: it didn't fire with [?the-fact <- [?user :user/loggedIn true]] as well - I don't see anything printed in the console

amarjeet 2018-03-12T20:41:21.000656Z

sorry, with [[?state :state/current-state :login-progress]] alone

amarjeet 2018-03-12T20:42:07.000098Z

I dont see anything printed if i add [?the-fact <- [?user :user/loggedIn true]] condition

amarjeet 2018-03-12T20:42:27.000368Z

and then log ?the-fact

amarjeet 2018-03-12T20:43:27.000662Z

So, even if [?user :user/loggedIn true] doesn't exist, ?the-fact should log something right?

alex-dixon 2018-03-12T20:44:39.000047Z

If I understand correctly, no. If the right hand side of the rule fires, then all the ruleā€™s conditions are true.

amarjeet 2018-03-12T20:45:07.000049Z

that means, the fact doesn't exist at the time of firing that rule

amarjeet 2018-03-12T20:45:27.000042Z

does it have to do something with then?

alex-dixon 2018-03-12T20:45:41.000408Z

?the-fact binds to the value of whole fact that matches [?user :user/loggedIn true]

alex-dixon 2018-03-12T20:46:08.000012Z

Can you log ?user when the rule fires?

alex-dixon 2018-03-12T20:47:05.000435Z

Because if the rule fires you should be able to log that as well as [?the-fact <- ...]

amarjeet 2018-03-12T20:47:19.000008Z

let me check again

amarjeet 2018-03-12T20:49:44.000531Z

No, its not getting logged - rule is not getting fired with user fact condition

amarjeet 2018-03-12T20:50:11.000089Z

It seems like something with then

amarjeet 2018-03-12T20:51:12.000168Z

when it inserts user fact at the time of api response

alex-dixon 2018-03-12T20:52:13.000452Z

Try removing ā€œtrueā€ from the condition. Maybe the else case of your if statement is evaluating?

amarjeet 2018-03-12T20:52:28.000407Z

So, the steps are: when I click on login button, state changes to :login-progress, and api call happens, which should have inserted user fact - these to combined, should fire the rule in question

alex-dixon 2018-03-12T20:52:58.000529Z

It could be a problem with then but Iā€™m not sure how. The fullstack examples and other work Iā€™m doing use the same pattern youā€™re using

amarjeet 2018-03-12T20:53:56.000325Z

hmm, let me try removing the true condition

alex-dixon 2018-03-12T20:55:06.000532Z

By doing that it should pick up a :user/loggedIn with anything in the value slot

amarjeet 2018-03-12T20:56:01.000226Z

the rule fires with ?user value null

alex-dixon 2018-03-12T20:56:12.000651Z

Kind of a side note but you can also see the state of the rules session at the end of each fire rules with @precept.state/store

alex-dixon 2018-03-12T20:56:16.000348Z

Ah hah!

amarjeet 2018-03-12T20:57:04.000640Z

@precept.state/store this should help in debugging

alex-dixon 2018-03-12T20:57:17.000356Z

Ok. So Iā€™m guessing line 14 of your snippet is running instead of line 9

amarjeet 2018-03-12T20:58:54.000142Z

actually no, I have tested with different set of rules - that is working fine. But, even with the 2nd condition, the ?user can't be null, because the fact is inserted with some id

alex-dixon 2018-03-12T21:00:50.000486Z

Hm. Well, Iā€™m guessing the reason the rule is firing now is because thereā€™s a :user/loggedIn fact that has a value slot of false. That would explain why previously when the condition only matched on the value true the rule wasnā€™t firing

alex-dixon 2018-03-12T21:01:43.000258Z

So you could try [?my-fact <- [?user :user/loggedIn]] and print the result of ?my-fact

amarjeet 2018-03-12T21:02:26.000135Z

yes, it is firing with false as well

alex-dixon 2018-03-12T21:02:36.000439Z

And hopefully it will be {:e nil :a :user/loggedIn :v false :t some number}. Otherwise Iā€™m lost

amarjeet 2018-03-12T21:03:16.000113Z

just a sec

alex-dixon 2018-03-12T21:03:16.000135Z

Ok. Do you insert :user/loggedIn false anywhere else?

amarjeet 2018-03-12T21:05:02.000119Z

I do get {:e nil :a :user/loggedIn :v false :t some number} kind of result

amarjeet 2018-03-12T21:05:06.000558Z

its pretty weired

amarjeet 2018-03-12T21:05:25.000514Z

:user/loggedIn is getting inserted only at the time of that api call

amarjeet 2018-03-12T21:06:04.000524Z

The other strange thing is - if you see in the app return value, along with the :user/loggedIn false, it also inserted id, so why are we getting id as nil?

amarjeet 2018-03-12T21:06:16.000039Z

in the api return value

alex-dixon 2018-03-12T21:06:16.000060Z

(defn auth [email password]
  (GET "<http://localhost:8080/login>")
       {:params {:email email
                 :password password}
        :handler #(if (:login-status %)
                    (then {:db/id (:id %)
                           :user/name (:name %)
                           :user/email (:email %)
                           :user/membershipId (:membershipId %)
                           :user/loggedIn true})
                    (then {:db/id (:id %)
                           :user/loggedIn false}))
        :error-handler #(.log js/console %)}))
Whatā€™s the % / result youā€™re getting here?

amarjeet 2018-03-12T21:06:45.000199Z

I printed %, and I got {:login-status true, :id 17592186045436, :name "Test User", :email "<mailto:test@gmail.com|test@gmail.com>", :membershipId "m0"}

alex-dixon 2018-03-12T21:10:12.000588Z

Wellā€¦hm. What happens when you do:

#(if (:login-status %)
                    (then {:db/id (:id %)
                           :user/name (:name %)
                           :user/email (:email %)
                           :user/membershipId (:membershipId %)
                           :user/loggedIn true})
                    (then {:db/id (:id %)
                           :user/loggedIn false}))

alex-dixon 2018-03-12T21:10:15.000521Z

oops

alex-dixon 2018-03-12T21:10:29.000511Z

Sorry one min

amarjeet 2018-03-12T21:16:25.000497Z

So, i just tested with a hard-coded :db/id (ex: 2345), and now it returns :id as 2345, but with value false

amarjeet 2018-03-12T21:16:36.000291Z

this is interesting šŸ™‚

alex-dixon 2018-03-12T21:17:02.000195Z

Sorry. Basically Iā€™m not convinced thatā€™s the result šŸ˜Š it could be that then isnā€™t parsing Booleans in maps correctly

amarjeet 2018-03-12T21:17:36.000259Z

hmm, i will just quickly use string and check

amarjeet 2018-03-12T21:23:10.000452Z

doesn't look like its a boolean parsing error, I am getting same results with string as well

alex-dixon 2018-03-12T21:23:24.000034Z

#(let [login-status (:login-status %)
          id (:id %)
          _ (println "Login status for id!" login-status id)
          (if login-status
            (let [facts [[id :user/name (:name %)]
                             [id :user/email (:email %)]
                             [id :user/membershipId (:membershipId %)]
                             [id :user/loggedIn true]]
                    (then facts))
           (let [facts [[id :user/loggedIn false]]
              (then facts))

alex-dixon 2018-03-12T21:23:47.000524Z

Sorry for the formatting and probably wrong parensā€¦

alex-dixon 2018-03-12T21:24:33.000043Z

But if you could try that, it should show whether the response is what you expect and also circumvent any bugs pertaining to maps by using the vector format instead

amarjeet 2018-03-12T21:24:46.000408Z

let me try

amarjeet 2018-03-12T21:31:55.000284Z

ites pretty weird, I am getting Login status for id! nil nil - so both login-status and id are nil

amarjeet 2018-03-12T21:32:46.000486Z

I am changing my back-end response type for login-status to string. Just a sec

alex-dixon 2018-03-12T21:33:33.000206Z

Is the response being parsed as EDN?

amarjeet 2018-03-12T21:35:28.000517Z

This is my response map

amarjeet 2018-03-12T21:35:32.000053Z

`{:login-status "true" :id user-id :name user-name :email stored-email :membershipId membershipId}`

amarjeet 2018-03-12T21:35:48.000408Z

changing login-status to string didnt help

amarjeet 2018-03-12T21:35:50.000526Z

same result

amarjeet 2018-03-12T21:36:30.000384Z

its ring/response

alex-dixon 2018-03-12T21:41:19.000481Z

Hm. Ok. Well, I think if you can get (:login-status) of the response to not be nil nil then everything else should work, with the rules the way you had originally

amarjeet 2018-03-12T21:42:07.000037Z

yeah, i think I will try the api call with cljs-http once

alex-dixon 2018-03-12T21:47:44.000502Z

Ok. Let me know how it works out or if I can be of any help

amarjeet 2018-03-12T21:53:48.000446Z

holy cow šŸ˜„

amarjeet 2018-03-12T21:53:56.000065Z

it worked with cljs-http response

alex-dixon 2018-03-12T21:54:17.000172Z

???

amarjeet 2018-03-12T21:54:25.000151Z

yeah, super strange

amarjeet 2018-03-12T21:54:48.000439Z

@amarjeet uploaded a file: https://clojurians.slack.com/files/U623NFZ17/F9NQYM077/-.clj

amarjeet 2018-03-12T21:55:05.000035Z

this is working

alex-dixon 2018-03-12T21:56:58.000012Z

Nice

amarjeet 2018-03-12T21:57:37.000269Z

Not sure what happened with Ajax

amarjeet 2018-03-12T21:58:13.000067Z

Anyway, a big thanks to you - you spent over one n half an hr with me on this. Really really appreciate it šŸ™‚

amarjeet 2018-03-12T21:58:19.000212Z

now I can sleep well

alex-dixon 2018-03-12T21:59:05.000026Z

Of course. Thanks for sharing your code. Looks really good šŸ™‚

1šŸ‘