Skip to content

Conversation

gioamato
Copy link
Contributor

No description provided.

@gioamato
Copy link
Contributor Author

• Fixed option naming, now it's track_null_params
• Added a check for current_session value to keep the paramaters during the session

Waiting for a confirmation about docs.

@medius
Copy link
Owner

medius commented Feb 17, 2020

To clarify, how about these requirements for this PR?

  • Keep the same behavior, i.e. use '' (empty string) in form field if a UTM value is not available.
  • Reset UTM values at the end of session if reset_params_at_session_end is set to true.

@gioamato
Copy link
Contributor Author

To clarify, how about these requirements for this PR?

  • Keep the same behavior, i.e. use '' (empty string) in form field if a UTM value is not available.
  • Reset UTM values at the end of session if reset_params_at_session_end is set to true.

Done. Let me know if everything is ok for you.

return c.substring(nameEQ.length, c.length)
value = c.substring(nameEQ.length, c.length)
if value != 'null'
return value
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than storing and managing 'null' string in cookies, we can choose not to store any null values.

If we update writeCookie method as follow, no null or empty string will be written.

 writeCookie: (name, value) ->
    if !!value
       @createCookie name, value, @_cookieExpiryDays, null, @_domain, @_secure
    return

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this way the initial parameters and the new feature reset_params_at_session_end will not work, breaking also the release 1.2.0.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please elaborate why won't those work? Also, in what ways does it break 1.2.0 release? I'm sorry, I'm a bit confused here.

I am hesitant to store 'null' strings in cookie and then ignore them while reading. It creates more cruft that need to be kept track of.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The initial_utm_params and additional_initial_params_map are based on the writeCookieOnce method that checks for cookie existence before writing it.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, if nothing is written, nothing will be read.

To be honest, I'm having a hard time following these changes which is a bad sign for something that's supposed to be simple. Perhaps I'm not thinking straight and need to revisit these when I have more spare time. Since you have your own fork, this doesn't block you from using these changes for your own use.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is super simple. As i said some methods are based on the writeCookieOnce one. This method will try to read the cookie before writing it. So if we don't write anything in the cookie it will always write the cookie. So we must store null, 0 or something in the cookie to keep the blank values, like in initial_utm_params.

If you don't want to store null values in the cookies then another way could be to use the visits counter and the current section cookie to "know" when the writeCookieOnce method should and should not write the cookie.

Let me know what you prefer. As i said, i have some spare time to do the job, no problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants