reagent-project / reagent-utils Goto Github PK

I think this could be made more efficient by using cursors.
As explained in News in 0.6.0 (very bottom):

Cursors are now cached, which should make them a bit easier to use. Previously, every instance of cursor had its own state. Now cursors called with the same arguments share data (...)

Thus, we could do the following and avoid re-rendering (or at least checking for changes) when only a subset of the state atom is changed:

(defn get
  "Get the key's value from the session, returns nil if it doesn't exist."
  [k & [default]]
  (let [temp-a (reagent/cursor state [k])]
    (or @temp-a default)))

Thoughts?

We upgraded from shadow-cljs 2.21.0 -> 2.22.0 today and started getting the following error:
The required namespace "goog.net.cookies" is not available, it was required by "reagent/cookies.cljs".

Turns out one of the shadow-cljs changes was to bump the google-clojure-library from an astonishly ancient v20211011 to a pretty recent v20230227.

Amongst the vast number of GCL releases between those two was v20220301, which included a change to "Delete deprecated goog.net.cookies". The message for that change states:

goog.net.cookies was deprecated and replaced by goog.net.Cookies some time ago.

So, we now move our attention to the reagent-utils lib, and specifically the cookies.cljs namespace. That require of goog.net.cookies seems suspicious, especially considering goog.net.Cookies is required on the line below.

This issue has been discussed on the Clojurians Slack instance.

I plan on putting a pull-request together that fixes this issue. Please let me know if I'm wasting my time doing that.

Small bug with the boolean logic in the set! function in cookies.cljs. It should be if-not rather than if

(if-not opts
      (.set goog.net.cookies k content)
      (.set goog.net.cookies k content (or max-age -1) path domain (boolean secure?)))

(session/put! "data" {"a" true "b" false "c" nil})
(session/get-in ["data" "a"]) ;returns true
(session/get-in ["data" "b"]) ;returns nil
(session/get-in ["data" "c"]) ;returns nil
(session/get-in ["data" "d"]) ;returns nil

There is no way to differentiate between cases b (key exists and is associated with false), c (key exists and is associated with nil), and d (key does not exist).

I would expect case b to return false, case c to return nil, and case d to return default argument (defaults to nil).

https://google.github.io/closure-library/api/goog.net.cookies.html

Especially the .set API which now takes an option map instead of individual option arguments.

Compiling a cljs which uses reagent.validation gives the following warnings

WARNING: Use of undeclared Var reagent.validation/Exception at line 63 file:/home/tcross/.m2/repository/reagent-utils/reagent-utils/0.1.0/reagent-utils-0.1.0.jar!/reagent/validation.cljs
WARNING: Use of undeclared Var reagent.validation/Exception at line 63 resources/public/js/out/reagent/validation.cljs

This looks to be due to the following code

(defn valid-number?
  "Returns true if the string can be parsed to a Long"
  [v]
  (try
    (js/parseFloat v)
    true
    (catch Exception e
      false)))

Perhaps the catch statement should be changed to

(catch js/Error e
   false)

or maybe

(catch :default e
    fales)

Likely related to some issues raised in the discussion around #19. For example this comment: #19 (comment)

I also had issues where max-age was not being applied on later versions of GCL even with proper dependencies applied for shadow-cljs. Found this relevant discussion on goog.net.cookies options usage where another person had the same issue with max-age. Apparently, passing options as JSON when setting cookies is insufficient as is currently done here:

Instead, the passed options object should support the goog.net.Cookies.SetOptions interface, either by creating a deftype with the same fields, or using SetOptions directly as mentioned in the linked discussion. In our case, we dropped to using GCL directly and either solution managed to resolve the issue with options not being properly applied in production builds.

Dear Sir,

Upon inspection of your utility library, in particular the namespace session, I have found myself perplexed by your lexicon. My first lamentation is the inconsistent naming in regards to put! and assoc-in!. I would venture to say that naming the latter put-in! would illuminate their familial nature. The second grievance being found in assoc-in! where by a lambda is used inside of the swap!. Correct me if I speak in ignorance but is (swap! state #(assoc-in % ks v)) not directly equivalent to the more terse, yet more legible owing to the smaller count of symbols, (swap! state assoc-in ks v)?

Good day.

😄

I try to set SameSite=None; Secure cookies but it doesn't seem to work. It seems like the max-age has no effect either. Previously, I at least had Secure cookies, when the SameSite option wasn't present.

...
[org.clojure/clojurescript "1.10.866"]
[reagent "0.10.0"]
[reagent-utils "0.3.4"]
[thheller/shadow-cljs "2.14.5"]
...

The behaviour is as desired besides the missing SameSite option with just these dependency changes:

[org.clojure/clojurescript "1.10.742"]
[reagent "0.10.0"]
[reagent-utils "0.3.3"]
[thheller/shadow-cljs "2.11.26"] (which brings with it ClojureScript 1.10.773 and that is the actually running version)

Would be nice to have support for SameSite as a cookie option.

This seems like a relevant place to add this,

• https://github.com/reagent-project/reagent-utils/blob/master/src/reagent/cookies.cljs#L6-L13

References,

• https://google.github.io/closure-library/api/goog.net.Cookies.SameSite.html
• https://www.owasp.org/index.php/SameSite
• https://web.dev/samesite-cookies-explained/

I have a random token "5wcDN..." stored in a cookie but am unable to read it back as the reader attempts to parse it as a number and throws 'Invalid number format'

Uncaught Error: Invalid number format [5wcDNnJcfcNJiJQ495qDiKE7YyX0SRMYe2iU36eW2uLKKdn066toSIS7nrQNAWLg%2FpWV2dKWXnyrCylm]
    at Function.cljs.reader.reader_error.cljs$core$IFn$_invoke$arity$variadic (reader.cljs:71)
    at cljs$reader$reader_error (reader.cljs:69)
    at cljs$reader$read_number (reader.cljs:301)
    at cljs$reader$read (reader.cljs:465)
    at cljs$reader$read_string (reader.cljs:477)
    at reagent$cookies$read_value (cookies.cljs:23)

Why does the get function make use of 'read-string' to read the value from the cookie ?

# taken from reagent.cookies starting line 21

(defn- read-value [v]
  (when v
    (reader/read-string v)))

(defn get
  "gets the value at the key, optional default when value is not found"
  [k & [default]]
  (or
    (->> (name k) (.get goog.net.cookies) read-value)
    default))

When not passing same-site, the value provided in Cookies.SetOptions is NONE. This won't even work in Chrome if secure? is not set to true.

Default browser value is LAX. A null can be passed in Cookies.SetOptions by default.

WARN: WARNINGS: reagent/cookies.cljs (1)
WARN: reagent/cookies.cljs:19 -> Use of undeclared Var reagent.cookies/secure