{"action":"created","issue":{"url":"https://api.github.com/repos/mozilla-frontend-infra/firefox-health-dashboard/issues/357","repository_url":"https://api.github.com/repos/mozilla-frontend-infra/firefox-health-dashboard","labels_url":"https://api.github.com/repos/mozilla-frontend-infra/firefox-health-dashboard/issues/357/labels{/name}","comments_url":"https://api.github.com/repos/mozilla-frontend-infra/firefox-health-dashboard/issues/357/comments","events_url":"https://api.github.com/repos/mozilla-frontend-infra/firefox-health-dashboard/issues/357/events","html_url":"https://github.com/mozilla-frontend-infra/firefox-health-dashboard/pull/357","id":422786854,"node_id":"MDExOlB1bGxSZXF1ZXN0MjYyNDk5Njk3","number":357,"title":"Use query-string to convert objects to url paramters, and back","user":{"login":"klahnakoski","id":2334429,"node_id":"MDQ6VXNlcjIzMzQ0Mjk=","avatar_url":"https://avatars3.githubusercontent.com/u/2334429?v=4","gravatar_id":"","url":"https://api.github.com/users/klahnakoski","html_url":"https://github.com/klahnakoski","followers_url":"https://api.github.com/users/klahnakoski/followers","following_url":"https://api.github.com/users/klahnakoski/following{/other_user}","gists_url":"https://api.github.com/users/klahnakoski/gists{/gist_id}","starred_url":"https://api.github.com/users/klahnakoski/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/klahnakoski/subscriptions","organizations_url":"https://api.github.com/users/klahnakoski/orgs","repos_url":"https://api.github.com/users/klahnakoski/repos","events_url":"https://api.github.com/users/klahnakoski/events{/privacy}","received_events_url":"https://api.github.com/users/klahnakoski/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2019-03-19T15:08:31Z","updated_at":"2019-03-20T15:55:10Z","closed_at":null,"author_association":"COLLABORATOR","pull_request":{"url":"https://api.github.com/repos/mozilla-frontend-infra/firefox-health-dashboard/pulls/357","html_url":"https://github.com/mozilla-frontend-infra/firefox-health-dashboard/pull/357","diff_url":"https://github.com/mozilla-frontend-infra/firefox-health-dashboard/pull/357.diff","patch_url":"https://github.com/mozilla-frontend-infra/firefox-health-dashboard/pull/357.patch"},"body":"Add more tests, get tests to pass"},"comment":{"url":"https://api.github.com/repos/mozilla-frontend-infra/firefox-health-dashboard/issues/comments/474898686","html_url":"https://github.com/mozilla-frontend-infra/firefox-health-dashboard/pull/357#issuecomment-474898686","issue_url":"https://api.github.com/repos/mozilla-frontend-infra/firefox-health-dashboard/issues/357","id":474898686,"node_id":"MDEyOklzc3VlQ29tbWVudDQ3NDg5ODY4Ng==","user":{"login":"klahnakoski","id":2334429,"node_id":"MDQ6VXNlcjIzMzQ0Mjk=","avatar_url":"https://avatars3.githubusercontent.com/u/2334429?v=4","gravatar_id":"","url":"https://api.github.com/users/klahnakoski","html_url":"https://github.com/klahnakoski","followers_url":"https://api.github.com/users/klahnakoski/followers","following_url":"https://api.github.com/users/klahnakoski/following{/other_user}","gists_url":"https://api.github.com/users/klahnakoski/gists{/gist_id}","starred_url":"https://api.github.com/users/klahnakoski/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/klahnakoski/subscriptions","organizations_url":"https://api.github.com/users/klahnakoski/orgs","repos_url":"https://api.github.com/users/klahnakoski/repos","events_url":"https://api.github.com/users/klahnakoski/events{/privacy}","received_events_url":"https://api.github.com/users/klahnakoski/received_events","type":"User","site_admin":false},"created_at":"2019-03-20T15:55:10Z","updated_at":"2019-03-20T15:55:10Z","author_association":"COLLABORATOR","body":"\r\n> What are all these functions in queryOps?  What does \"frum\" mean?  \"leaves\"?  If that library is a part of the frontend infra catalog, then I can't find it, nor the documentation for it.  And not understanding that makes it difficult for me to understand the code.\r\n\r\nThat is part of another conversation; finding a name for wrapping an array for chained vector operations, just like Lodash, but Lodash is too big.\r\n\r\nHere is some background\r\nhttps://github.com/mozilla-frontend-infra/firefox-health-dashboard/pull/291#issuecomment-461509013\r\n\r\nHere are two name proposals\r\nfluent - https://github.com/mozilla-frontend-infra/firefox-health-dashboard/pull/359\r\nvector - https://github.com/mozilla-frontend-infra/firefox-health-dashboard/pull/340\r\n\r\n> Why are patches occurring in a \"vendor\" directory?  Is that with the intent to upstream these patches to their source?\r\n\r\nRight now the vendor directory is wholly owned by firefox-health. Our frontend-infra discussions will guide what the canonical directory will look like. \r\n \r\n> Why are the query strings for this particular application unique and requiring handling of type conversion?  \r\n\r\nSince a React app passes query parameters to itself it should have `obj` be structurally equal to `parse(stringify(obj))`.  This identity keeps the code clean because it need not compensate for the lossy conversion.\r\n\r\n> The `qs` library parses the \"80%\" of queries, and using that has the advantage of forcing the app to use query strings in a way that is not surprising to others.  \r\n\r\nExcellent! if the qs library works then we can use that. I will see how it passes the test cases (which I will also relax).\r\n\r\n> Is there a possibility to simplify the formatting of the query strings wherever they are generated, so that a thin wrapper over `qs` could parse them?\r\n\r\nI see no distinction between a \"thin wrapper\" and a custom library, especially in the face of a test suite:  Both expose a new, unfamiliar, API.  If we can avoid the thin wrapper, then everyone is happy.\r\n\r\n> Speaking of surprise, type inference on untrusted data could lead to unexpected behavior, which could lead to security issues.  Obviously not in a frontend-only app, but if this library were used on the backend, then a parameter where a user chooses to write \"0\" or \"null\" instead of the expected string might result in a falsy value where one is not expected.\r\n\r\nThis is only meant for frontend dashboard code; there are no plans to make servers. Even so, verifying query encoding and verifying logical parameters are different levels of abstraction which I imagine are verified in different parts of the code.\r\n\r\n> How would a user pass the string \"null\" using this library?\r\n\r\n    http://example.com?a=null\r\n\r\nyou are right to point out that inconsistency.\r\n\r\n> Why not use an existing type-preserving and well-tested encoding like JSON?\r\n\r\nI was working under the assumption that the query string be humane. Without being bound so such concerns, the encoding logic is easier:\r\n\r\n    {\"test\":42}  <=>  http://example.com?%7B%22test%22%3A42%7D\r\n"}}
{"actor":{"display_login":"klahnakoski"}}