profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/ethanresnick/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.

ethanresnick/civem 4

Italian Verb Conjugator

ethanresnick/diceware-js 4

Easily generate secure, memorable passwords using the Diceware password system

ethanresnick/ConditionalSection 3

JS library for implementing three UI elements that support progressive disclosure.

ethanresnick/EnhancedVerticalRhythm 3

Better Vertical Rhythm Implementations by Exposing Line Counts to CSS.

equivalent/json-api-RC3 2

A specification for building JSON APIs - Mirror to RC3

ethanresnick/chai-jest-snapshot 1

Chai assertion that provides Jest's snapshot testing

AbhiAgarwal/vagrant-tnyu 0

Tech@NYU website running on Vagrant

duwaynevandort/node-env-run 0

🏃 Node script to load .env variables and execute the give Node file afterwards

ethanresnick/autocomplete 0

🔮 Fast and full-featured autocomplete library

startednim-lang/Nim

started time in 3 days

startedabpframework/abp

started time in 8 days

issue commentradix-ui/primitives

[Portal] Explore giving more control for layering

I would also love to see this. My use case is that I have a form inside a dialog; if form submission fails, I show an error message in a toast widget [which is more consistent with the rest of our UI than putting the error message inside the dialog content]. Right now, the dialog overlay is covering up the toast, which obviously needs to be on top.

jjenzz

comment created time in 13 days

issue commentmodulz/stitches

Stitches throwing exceptions "TypeError - Converting circular structure to JSON"

@peduarte Thanks! Very helpful to know about that workaround with the version pinning. That should be enough for our project right now

tiagogm

comment created time in 17 days

issue commentmodulz/stitches

Stitches throwing exceptions "TypeError - Converting circular structure to JSON"

@peduarte @jonathantneal Any sense of what's involved in fixing this, and what the ETA is? Not trying to look the open-source gift horse in the mouth; I'm just curious so that I can prepare accordingly, as my project currently depends on a library (the Google Maps API) that creates one of these circular references, which makes it impossible to use stitches.

tiagogm

comment created time in 18 days

push eventethanresnick/react-block-ui

Ethan Resnick

commit sha 58ea948ad5fe7df826f95709c8c2133c76025dc3

deps: republish for react 17

view details

push time in a month

fork ethanresnick/react-block-ui

Easy way to block the user from interacting with your UI.

https://availity.github.io/react-block-ui/

fork in a month

issue commentmodulz/stitches

Allow component authors to force component consumers to provide the `as` prop

Actually, one thing that's interesting here... in our design system, we have more heading styles than there are HTML heading tags — we have 9. So, if I make components like H1-H9, some of them will have to reuse some of the HTML heading tags, which means the component name refers to the heading level in our design system rather than the heading level in HTML. This leads to the odd result that something like this is possible:

const H9 = styled('h6', baseHeading, {
  defaultVariants: {
    size: '9'
  }
});


// At time of component use...
<H9 size="7">....</H9>

So we've defined a component called H9, where the only sensible interpretation of its name is that it's referring to styles for the 9th subheading in our design system, and yet the caller can render it with the styles for our 7th size. That's not necessarily a dealbreaker, but it does seem like one argument for having only a single <Heading> component. (I.e., if the style is gonna be changeable with a size prop, then a single component prevents a mismatch between component name and style level.)

ethanresnick

comment created time in a month

issue commentmodulz/stitches

More expressive ways to express compound variants

My I'm guessing the source of the problem is the fact that you are adding border radius in the size variant. So then you're forced to remove the border radius via an unrounded variant.

You're right: applying a radius as part of the size variant's styles was complicating things a lot. I was porting this component from an old design system and not thinking enough about how to refactor it.

Even making radius totally orthogonal to size, though, I am still ending up with a bit of repetition in my compoundVariants. To borrow your naming scheme, I actually have a shape variant with three values: "square" | "rounded-rect" | "pill"; at rounded-rect shape, the radius is always set, but some sizes use the same value, so I have something like:

[{
  shape: "rounded-rect",
  size: "small",
  css: {
    borderRadius: "2px",
  },
},
{
  shape: "rounded-rect",
  size: "normal",
  css: {
    borderRadius: "2px",
  },
},
{
  shape: "rounded-rect",
  size: "large",
  css: {
    borderRadius: "3px",
  },
},
{
  shape: "rounded-rect",
  size: "xl",
  css: {
    borderRadius: "3px",
  },
}]

The repetition there is really just a result of me clipping the border radius values to values from our design system. I.e., conceptually, maybe the rounding on the normal size button should be 2.5px or something, but we instead make it 2px (matching the small variant's rounding) since we don't otherwise use 2.5px border radii.

It'd be nice to be able to instead write:

[{
  shape: "rounded-rect",
  size: ["small", "normal"],
  css: {
    borderRadius: "2px",
  },
},
{
  shape: "rounded-rect",
  size: ["large", "xl"]
  css: {
    borderRadius: "3px",
  },
}]

And an extension like that of the compoundVariants syntax really does seem to me like it would be generally useful.

ethanresnick

comment created time in a month

issue commentmodulz/stitches

Allow component authors to force component consumers to provide the `as` prop

@peduarte I didn't think about pulling out the base styles using css, and that certainly makes this less clunky than I imagined. So I guess I'm content with that solution. Happy to close this, or can leave it open if there are any other use cases where component authors might want the ability to force users to pick the base component explicitly.

ethanresnick

comment created time in a month

issue commentmodulz/stitches

Stitches throwing exceptions "TypeError - Converting circular structure to JSON"

I tried this in 1.2.0 and I think it's still not fixed?

tiagogm

comment created time in a month

issue openedmodulz/stitches

More expressive ways to express compound variants

Is your feature request related to a problem? Please describe. Here's an example:

I have a Button component that has different size variants, which control the text size, padding, etc. Each size variant sets a different borderRadius, where bigger sizes get a bigger radius, but the size of the radius isn't exactly proportional to the text size (so it can't just be one constant value [e.g., in ems], and does have to be different for each variant).

Now, I also want to have a boolean variant — unrounded — that sets borderRadius: 0, regardless of the size. My sense is that the only way to do this today is to make a compound variant for each (size, unrounded) pair, as in:

{
  compoundVariants: [
    {
      size: "small",
      unrounded: true
      css: {
        borderRadius: 0,
      },
    },
        {
      size: "medium",
      unrounded: true
      css: {
        borderRadius: 0,
      },
    },    {
      size: "large",
      unrounded: true
      css: {
        borderRadius: 0,
      },
    },    {
      size: "xl",
      unrounded: true
      css: {
        borderRadius: 0,
      },
    },
  ];
}

That feels quite clunky/verbose.

Describe the solution you'd like In thinking about this, I'm realizing that I don't fully understand the current stitches API contract when multiple variants with conflicting styles apply, and there is no compoundVariant defining their interaction. That is, if I'd just defined unrounded as a normal, boolean variant that set borderRadius to 0 [with no compoundVariant], then the Button would have two conflicting borderRadius values — one from the size and one from unrounded — and I'm not sure if there's a current mechanism in the stitches API for controlling which declaration should override the other. If there is, then that would solve this use case. But, since I didn't see it documented, my guess is that the behavior in such a case is intentionally undefined, and that strikes me as the right approach, since overrides and precedence rules are much harder to learn and work with reliably than the explicit, opt-in matching of compoundVariants.

So I'd like some approach that makes it easier to express multiple combinations of variants in a more concise way. Here are some possibilities:

// accept an array of values for variants in the compound variant. Seems like a simple, logical extension of the current API.
{ unrounded: true, size: ["small", "medium", "large", "xl"], css: { borderRadius: 0 } }

// define some sort of "wild card" token so that all the values for size don't have to be enumerated explicitly/kept in sync.
// `any` would be a symbol exposed by the stitches package.
{ unrounded: true, size: any, css: { borderRadius: 0 } }

// the wildcard could also be a string, which saves an import and is maybe more intuitive 
// (leveraging common meaning of '*'), though this is going down the road of turning the string value
// into some variant-value matching grammar, which could be fine
{ unrounded: true, size: "*", css: { borderRadius: 0 } }

// Finally -- and idk the implementation implications of this, though i can imagine that it might make 
// certain optimizations harder -- users could provide a predicate fn to indicate if the compound variant matches.
{ test: (variants) => variants.unrounded, css: { borderRadius: 0 } }

Describe alternatives you've considered See above.

Additional context No

created time in a month

issue openedmodulz/stitches

Allow component authors to force component consumers to provide the `as` prop

Is your feature request related to a problem? Please describe. The feature request is pretty well captured by the title, I think. But here's an example use case:

I'd like to make a generic Heading component, which would have a different size variants to control how big the text is. The issue is that it's very difficult to know what HTML element this component should render:

  • the visually-bigger headings likely want a higher-numbered <hx> tag, but I want a single Heading component, not a different component for each tag <h1>-<h6> that might be appropriate;
  • even if I had multiple components that used different default <hx> tags, I might want the user to have to consciously pick a heading level for semantic/SEO reasons, accounting for the other headings on the page.

Describe the solution you'd like One possible API I'd like is for the author of the component to be able to use null to indicate that the component user must provide the base element/component, as in:

const Heading = styled(null, { 
  variants: { 
    size: { 
      1: { fontSize: 30 },
      2: { fontSize: 25 },
      // ... etc
    }
  }
});
// user of component... omitting `as` triggers a type and/or runtime error
<Heading as="h1" size={1}>Some text</Heading>

Describe alternatives you've considered For solving this specific use case, I considered creating multiple components (const H1 = styled("h1", ...); const H2 = styled("h2", ...)), but rejected that because it's clunkier (lots more to define -- and then to import everywhere), and it still doesn't force the component user to opt-in to an appropriate heading level.

Beyond this one use case, I didn't spend too much time thinking about alternate APIs, but many could work.

Additional context Add any other context or screenshots about the feature request here.

created time in a month

issue commentdotnet/csharplang

[Proposal] Allow overriding single accessor properties with multiple accessors

This should also apply when the overridden property has a covariant type, as discussed in #5179. In that case, the ability to add a setter in the child class may be especially important, since there's no way to define even a dummy setter in the parent class (that just throws) without the compiler complaining about a legitimate type safety issue.

MrJul

comment created time in a month

startedcallstack/linaria

started time in a month

startedrobinweser/fela

started time in a month

startedlinkedin/opticss

started time in a month

startedarctic-hen7/diana

started time in 2 months

startedSilind-Software/direflow

started time in 2 months

startedfake-name/pg-spgist_hamming

started time in 2 months

startedjeanqasaur/learn-programming-languages

started time in 2 months

startedgraninas/software-design-in-haskell

started time in 3 months