profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/gaurav5430/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

gaurav5430/100-days-of-code 0

Fork this template for the 100 days journal - to keep yourself accountable (multiple languages available)

gaurav5430/babel-loader 0

📦 Babel loader for webpack

gaurav5430/cz-cli 0

The commitizen command line utility.

gaurav5430/DefinitelyTyped 0

The repository for high quality TypeScript type definitions.

gaurav5430/dioterms 0

Open-source vulnerability disclosure policies.

gaurav5430/eslint-config-prettier 0

Turns off all rules that are unnecessary or might conflict with Prettier.

gaurav5430/fuzzy-search 0

Javascript Fuzzy Search

gaurav5430/gaurav5430.github.io 0

for hosting json data

issue commentw3c/aria-practices

Disclosure pattern - hiding the trigger after expanding the content

Sure, I agree to many of the points mentioned (partially)

Regarding bad design, sure, can try to push the design team for fixing this. These patterns do exist a lot in the wild though.

One quick example from GitHub

the "more" option on the homepage of this repository, on mobile app, when activated, gets hidden and reveals 3 previously hidden options. There is no way to go back to the hidden state now.

gaurav5430

comment created time in 4 days

issue openedw3c/aria-practices

Disclosure pattern - hiding the trigger after expanding the content

Consider this scenario:

There is a "Read more" button which shows some extra content when activated, but once expanded, we don't want the user to be able to collapse the content once again as it does not make sense in the use case, and so we would like to remove the "Read more" button from the DOM altogether.

How should something like this be exposed to the screenreader ?

I am guessing we can start with aria-expanded=false on the button, so that users know that there is something to be shown on activating the button, and once activated, if we remove the button from the DOM altogether and place focus on the newly shown content, it should be alright?
Would users be expecting a "Read less" toggle to still be available? Since we remove the button from the DOM altogether, there wouldn't be any element now which says aria-expanded=true, would that be confusing ?

created time in 5 days

issue commentphotonstorm/phaser

Safari's bizarre caching of CORS resources breaks preloading

slightly unrelated, but I am facing a similar issue with preloading fonts in safari, where it caches the font requested from css (without CORS headers) and tries to use that in preload request in subsequent refresh (which requires CORS) and hence the preload request fails

Is there a webkit bug / more info about the safari caching idiosyncrasies for CORS resources ?

toolness

comment created time in 5 days

pull request commentmicrosoft/TypeScript

Fix 'as const'-like behavior in JSDoc type cast

TypeScript has a set release schedule, the next release details are here: https://github.com/microsoft/TypeScript/issues/45418

can't see it in the plans for 4.5 is that right or am I missing something ?

rbuckton

comment created time in 9 days

issue openeda11yproject/a11yproject.com

Article: [Nested interactive elements accessibility]

Delete this boilerplate or any other information that doesn't apply to your article.

Please review our Code of Conduct, Contributor documentation, and Content Style Guide before submitting content.

Description

A brief description (2-3 sentences) of your proposed article. Why should this article be written, and how does it fit on The A11Y Project?

The article would discuss why having nested interactive elements in the markup is a problem for accessibility. This article would mostly talk about this issue in the web (HTML + js) context

  • what is the issue?
  • why /when can it happen?
  • some proposed solutions with links to existing resources / discussions.

This article should be written to apprise developers / designers about issues with nested interactive elements, and how they can solve them by paying a bit more attention initially.

Would you like to write the article or request that it be written?

I would like to write an article (but also get the discussed solutions verified by other people)

Are you posting this as a means to look for help on the topic or do you have a method you've developed/tested to solve the issue/topic?

I have a few patterns /exmaples which can solve the issue

created time in 10 days

issue commentrecharts/recharts

Change Line color depending on value

@arianitu yeah I figured something for my use case, might be helpful in general as well. I ended up using gradients as I only had the requirement to change color after a certain value.

What exactly are you trying to achieve?

hi @gaurav5430 i want to achieve similar to yours, can you please help me here. i want to color the line of linechart with red if value is <100 and if value in >100 then i want to color the line as green in the same LineChart

is this not helpful

https://github.com/recharts/recharts/issues/407#issuecomment-647135045

belgac

comment created time in 11 days

issue commentw3c/aria-practices

Accordion Pattern

oho, regarding the 3rd point, I guess I understand

the header button would be wrapped in a heading and hence the expanded panel would not be a direct sibling of the button, and so aria-controls would be helpful

gaurav5430

comment created time in 14 days

issue openedw3c/aria-practices

Accordion Pattern

I have some doubts which are not directly addressed in the description / example of the accordion Pattern

  • it is mentioned that the header has to be a button element, and everything inside the header should be a child of the button. Why is that? Can we not implement an accordion header where only the chevron / icon is interactive and shows/hides the panel (and the rest of the text is non interactive? if yes, would the same aria practices as mentioned in the example still apply ?

  • about the variant where partial text is always visible in the panel, would it still be ok to

    • use aria-expanded = false when the partial content is visible?
  • is it mandatory to use aria-controls even if the expanded content is just next in the DOM ?

created time in 14 days

issue commentmixpanel/mixpanel-js

option to not send the full url in initial referrer / referrer

also, as a last resort, I am assuming that mixpanel might be reading the initial referrer url information from document.referer which can be controlled by the referrer policy, so that only the domain gets captured and not the full url

gaurav5430

comment created time in 15 days

issue commentmixpanel/mixpanel-js

option to not send the full url in initial referrer / referrer

not sure if the previous comment was sarcastic 😅

but yeah, we don't control the tokens that gets appended in the initial referrer url (consider it a 3rd party login, which just redirects to our app with a token in the url), and sometimes these tokens are not one time use. So effectively, if anyone can get that url with the token, they could just revisit the same url and get logged in as the previous user

what we do from our side as an added handling is that we replace the url with the post log in url (instead of pushing the post log in url) so it doesn't end up in browser history (atleast directly). This does not fix everything ofcourse and there are still ways to get the url, one of which is the automatic initial referrer url captured by mixpanel.

gaurav5430

comment created time in 15 days

issue commentmixpanel/mixpanel-js

option to not send the full url in initial referrer / referrer

umm, sure, but I am also slightly worried about having this cookie / localstorage on a shared computer, where the next person can see the cookie / local storage and get the initial referrer url (which would automatically log the user in, in our setup)

gaurav5430

comment created time in 15 days

issue commentmixpanel/mixpanel-js

option to not send the full url in initial referrer / referrer

thanks that sounds do-able

i am assuming this will only impact the track calls though, or does this impact the initial referrer saved in the cookie as well?

gaurav5430

comment created time in 15 days

issue commentoutline/outline

Mention/tag users in a document

is this being worked on (or already implemented) ?
can't find mentions of this in the README, so assuming it is not yet available.

miluoshi

comment created time in 18 days

issue commentlerna/lerna

consume monorepo packages in consumer without publishing a new version

we have resorted to publishing beta versions for testing and then unpublishing them :(, as we publish everything on our internal npm registry and we know who are the consumers and that they wouldn't be using the beta versions

not ideal, but works for our small team setup

gaurav5430

comment created time in 19 days

issue openedmixpanel/mixpanel-js

option to not send the full url in initial referrer / referrer

I can see that the initial referrer / referrer are capturing the full url which sometimes contains sensitive data as well. I would like to somehow filter / mask this information while mixpanel is capturing these urls. Is there a way to do so?

(I understand that properties can be blacklisted, but that is not what I want, I would still like to send the value, but with some part of the url masked or removed)

created time in 19 days

issue closedmixpanel/mixpanel-js

Setting cookie only on a subdomain

We have a Saas product which we host on our partners domain (partner.com), as a subdomain (ourproduct.partner.com). The analytics / tracking for our product belongs to us and we use mixpanel along with other analytics libraries. The partner may have their own mixpanel setup on the top level domain. It seems that our mixpanel instance is setting the cookie on .partner.com instead of ourproduct.partner.com. this means that our cookie is visible to the partner top level domain, and would also interfere with their mixpanel

is there a way to set the cookie only on the specific subdomain that our app runs on?

closed time in 19 days

gaurav5430

issue commentmixpanel/mixpanel-js

Setting cookie only on a subdomain

Thanks, this works, and now I understand the reason why.

gaurav5430

comment created time in 19 days

issue commentgajus/babel-plugin-react-css-modules

Passing multiple style props to a child component

Oh, going through the readme, stumbled across the Custom attribute mapping. Would the Custom attribute mapping / attributeNames map help with this?

gaurav5430

comment created time in 20 days

issue openedgajus/babel-plugin-react-css-modules

Passing multiple style props to a child component

I have a child component, which accepts multiple props for styles, one for the container, and other for one of the internal elements. Generally, I would just name them something like className and elementClassName, and get different css classes from the parent in each of the props. With react-css-modules though, since the default rule only allows converting styleName to className, I can not pass different local classes in multiple props, as i can only have 1 styleName prop.

One of the way around this seems to be to use named imports instead of anonymous imports and then pass styles.containerClass in className and styles.elementClass in elementClassName prop. This does not require using the styleName prop at all.

import styles from './some.css';

...
...
<Component className={styles.containerClass} elementClassName={styles.elementClass} />

...
...

This seems alright, and the other existing styleName in the file do not break, still work alright and do not need to be changed to styles.soemthing, but it is slightly confusing that the named import is being only used at one place, and at the rest of the places the anonymous string value in styleName still works fine.

Is there another preferred / prescribed approach to handle the above scenario?

created time in 20 days

issue commentmixpanel/mixpanel-js

Setting cookie only on a subdomain

it seems like the cross_subdomain_cookie: false works, I am still not clear on why it works though ?

This is what I got from support:

Thank you for contacting Mixpanel support. The default cross_subdomain_cookie config is set to true in your mixpanel.init function, which will allow your subdomain's cookie to be stored and keep the Mixpanel distinct ID and super properties consistent across the sub-domain: mixpanel.init(PROJECT_TOKEN,{cross_subdomain_cookie:true}); Or, use a CNAME to change from yourdomain.partner.com to yourdomain.com.

gaurav5430

comment created time in 22 days

issue commentfacebook/react

DOM Selector VS React Ref Performance

are there any other benefits of using refs over query selector (or others) ? For example, refs may be aware of the react virtual dom or the react component lifecycle because they work inside react, whille query selector would not? does this matter?

hg-pyun

comment created time in a month

issue commentfacebook/prop-types

Why react should be declared as peerDependencies and prop-type as dependency ?

with a monorepo setup, where a lot of packages from the monorepo are going to be used across consumers, we have figured that it makes sense to just add it as a peer dependency instead of a dependency. I mean, it could very well be a dependency sure, but it just makes sense to treat it as other dependencies

pgn-vole

comment created time in a month

pull request commentfacebook/react

Remove the warning for setState on unmounted components

Yeah, sorry, I was not trying to prove a point. Just stating publicly to get feedback on my understanding.

My observation related to this warning was mostly around this particular usage: api call subscription and unsubscribe which we use a lot in our codebase, and hence this whole conversation.

To sum up my understanding, from this conversation it seems that:

  • the data fetching or any promise based use case is either rare enough or not (easily) solvable, so this warning does not really contribute to the solution.
  • there are some actual / valid use cases like store subscriptions, (they can be abstracted and solved at coomon places) and the drawbacks or antipatterns due to this warning far outweigh them
gaearon

comment created time in a month

pull request commentfacebook/react

Remove the warning for setState on unmounted components

But this is already a problem today anyway! Just adding if (!isMounted) does not unsubscribe you from anything. In fact there is no way to "unsubscribe" from a Promise. So what you're describing is already how the code that tries to avoid the warning works today. For these cases, the warning is not effective in any way. And like I said earlier, there's no particular concern because it only lives as long as the fetch itself.

yeah, this is a problem,

  • people tend to notice this problem because of the existing warning for unmounted setState
  • the isMounted solution is not valid in this case, but we can use implementation specific promise cancellation to unsubscribe (?)

as you said, possibly the promise gets garbage collected soon because no one else is referencing it, but possibly not, who knows what else is referencing that promise. Though it may not be for the lifetime of the app (which I wasn't really sure of, because of limited understanding of how promise garbage collection exactly works, but would take your word for it), it is still a memory leak. This is my most common use case for this warning.

May be not as much a concern as a store.subscribe or event listeners, which are valid for the lifetime of the app, so yeah, fine I guess.

gaearon

comment created time in a month

pull request commentfacebook/react

Remove the warning for setState on unmounted components

(just to be clear, I am NOT suggesting to not remove the warning, just trying to understand better the motivation behind it)

gaearon

comment created time in a month

pull request commentfacebook/react

Remove the warning for setState on unmounted components

None of the cases discussed in this thread have any relation to data fetching. They're about mutations — sending a form, posting a message, and so on. Mutations belong in the event handlers, while regular data fetching, like you say, usually belongs in lifecycles/effects. Nothing has changed here.

Apologies, the second part of my comment about the data fetching was based on my first observation (explained in the previous comment), the get api call / data fetch in componentDidMount.

I considered async operations and mutations to be treated similarly in extension the examples you provided, because mutations and async operations both may be related to lifecycle or user actions. For example:

  • firing a tracking event on component mount (mutation in lifecycle)
  • changing the page title on component mount (mutation in lifecycle)
  • fetching some data on button click (data fetching on user action)
  • fetching data when the component mounts (data fetching in lifecycle)
  • submitting a form on user action (mutation on user action)

considering the above, are you suggesting that some of the cases would remain as is (data fetching), some of them would be solved better without this warning (mutations on user action) ? (I am just trying to understand why should we treat them differently)

gaearon

comment created time in a month

pull request commentfacebook/react

Remove the warning for setState on unmounted components

The "less common" case (a store subscription) has no relation to API calls or Promises. What do you mean?

I was talking about a get api call which sets component state in .then

This is a subscription, which the component should unsubscribe to on unmount, and it is a valid use case for having this warning, as the component instance is kept in memory because of using setState in .then

isn't that understanding correct ?

gaearon

comment created time in a month

Pull request review commentfacebook/react

Remove the warning for setState on unmounted components

 describe('ReactCompositeComponent', () => {     expect(renders).toBe(1);      instance.setState({value: 1});-     expect(renders).toBe(2);      ReactDOM.render(<div />, container);--    expect(() => {

since we are not asserting anything here now, wouldn't this test pass even if the actual implementation DID throw a warning ?

gaearon

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent