Brandon McConnell
@brandonmcconnell.com
Find me on 𝕏 @ https://x.com/branmcconnell
Software Engineer ⚡️ Crafting some of the most popular Tailwind CSS plugins around. Bugs are my own. Dev-tooling & spec-reading fanatic 💻 #codeinpublic
Software Engineer ⚡️ Crafting some of the most popular Tailwind CSS plugins around. Bugs are my own. Dev-tooling & spec-reading fanatic 💻 #codeinpublic
Thanks! I emailed you
October 12, 2025 at 3:26 PM
Thanks! I emailed you
This is backward. How is canceling a debate promoting free speech?
Promoting free speech would mean promoting open debate. This is exactly the opposite.
Promoting free speech would mean promoting open debate. This is exactly the opposite.
September 22, 2025 at 7:45 PM
This is backward. How is canceling a debate promoting free speech?
Promoting free speech would mean promoting open debate. This is exactly the opposite.
Promoting free speech would mean promoting open debate. This is exactly the opposite.
where were you in the last presidential term where the left continually celebrated politicians, doctors, and reporters alike getting silenced and canceled?
if free speech died, it happened long before now
if free speech died, it happened long before now
September 22, 2025 at 7:43 PM
where were you in the last presidential term where the left continually celebrated politicians, doctors, and reporters alike getting silenced and canceled?
if free speech died, it happened long before now
if free speech died, it happened long before now
I'm happy to open an issue for this as well, except there's a fair chance I'm just doing something wrong. 😅
I really appreciate you maintaining such a great plugin. I know a lot of work goes into that. I'm happy to compensate you for any time spent on this if you like.
I really appreciate you maintaining such a great plugin. I know a lot of work goes into that. I'm happy to compensate you for any time spent on this if you like.
August 1, 2025 at 7:48 AM
I'm happy to open an issue for this as well, except there's a fair chance I'm just doing something wrong. 😅
I really appreciate you maintaining such a great plugin. I know a lot of work goes into that. I'm happy to compensate you for any time spent on this if you like.
I really appreciate you maintaining such a great plugin. I know a lot of work goes into that. I'm happy to compensate you for any time spent on this if you like.
Yeah, that's how I've been doing it so far, but targeting specific elements would be pretty neat
June 22, 2025 at 3:18 AM
Yeah, that's how I've been doing it so far, but targeting specific elements would be pretty neat
Yes, I actually made that switch right after sending you that message haha
Still, how would you avoid useEffect here, if you would? I'm waiting until the session is ready to know if the user is logged in or not.
Still, how would you avoid useEffect here, if you would? I'm waiting until the session is ready to know if the user is logged in or not.
June 19, 2025 at 11:23 PM
Yes, I actually made that switch right after sending you that message haha
Still, how would you avoid useEffect here, if you would? I'm waiting until the session is ready to know if the user is logged in or not.
Still, how would you avoid useEffect here, if you would? I'm waiting until the session is ready to know if the user is logged in or not.
Yes, a lot of this boils down to the desire for nested components.
I generally advocate for separating concerns and moving complex logic into new components, but I often have to do this for a simple conditional and nested pieces of composition simply to hold state.
I’d love nesting!
Thanks again!
I generally advocate for separating concerns and moving complex logic into new components, but I often have to do this for a simple conditional and nested pieces of composition simply to hold state.
I’d love nesting!
Thanks again!
May 17, 2025 at 7:51 PM
Yes, a lot of this boils down to the desire for nested components.
I generally advocate for separating concerns and moving complex logic into new components, but I often have to do this for a simple conditional and nested pieces of composition simply to hold state.
I’d love nesting!
Thanks again!
I generally advocate for separating concerns and moving complex logic into new components, but I often have to do this for a simple conditional and nested pieces of composition simply to hold state.
I’d love nesting!
Thanks again!
BUILD PLUGIN (4/4)
This approach seems to have the fewest gotchas and simplifies the syntax, making it feel more native.
My biggest hesitation with this approach is that I believe in “Just JavaScript,” and while this would be JS, it feels more magical since it happens outside of React.
This approach seems to have the fewest gotchas and simplifies the syntax, making it feel more native.
My biggest hesitation with this approach is that I believe in “Just JavaScript,” and while this would be JS, it feels more magical since it happens outside of React.
May 17, 2025 at 4:55 PM
BUILD PLUGIN (4/4)
This approach seems to have the fewest gotchas and simplifies the syntax, making it feel more native.
My biggest hesitation with this approach is that I believe in “Just JavaScript,” and while this would be JS, it feels more magical since it happens outside of React.
This approach seems to have the fewest gotchas and simplifies the syntax, making it feel more native.
My biggest hesitation with this approach is that I believe in “Just JavaScript,” and while this would be JS, it feels more magical since it happens outside of React.
BUILD PLUGIN (3/4)
Immediately, I could replace that <$> wrapper with a familiar-feeling string directive, like 'use render' (or similar).
Any block using that directive would immediately be broken out into a separate component.
Immediately, I could replace that <$> wrapper with a familiar-feeling string directive, like 'use render' (or similar).
Any block using that directive would immediately be broken out into a separate component.
May 17, 2025 at 4:55 PM
BUILD PLUGIN (3/4)
Immediately, I could replace that <$> wrapper with a familiar-feeling string directive, like 'use render' (or similar).
Any block using that directive would immediately be broken out into a separate component.
Immediately, I could replace that <$> wrapper with a familiar-feeling string directive, like 'use render' (or similar).
Any block using that directive would immediately be broken out into a separate component.
BUILD PLUGIN (2/4)
Something great about this approach is that as long as the pre-compilation is robust and works effectively, I could simplify the syntax even further.
Right away, we remove the need to use a callback; we can simply match any content wrapped in syntax like <$> and expand that.
Something great about this approach is that as long as the pre-compilation is robust and works effectively, I could simplify the syntax even further.
Right away, we remove the need to use a callback; we can simply match any content wrapped in syntax like <$> and expand that.
May 17, 2025 at 4:55 PM
BUILD PLUGIN (2/4)
Something great about this approach is that as long as the pre-compilation is robust and works effectively, I could simplify the syntax even further.
Right away, we remove the need to use a callback; we can simply match any content wrapped in syntax like <$> and expand that.
Something great about this approach is that as long as the pre-compilation is robust and works effectively, I could simplify the syntax even further.
Right away, we remove the need to use a callback; we can simply match any content wrapped in syntax like <$> and expand that.
BUILD PLUGIN (1/4)
e.g. Vite/Webpack/etc.
In this approach, I would pre-compile any uses of this <$> syntax and *actually* break its usage out into separate functional components within the same file.
Natural hoisting makes this even easier because we don’t have to worry about order.
e.g. Vite/Webpack/etc.
In this approach, I would pre-compile any uses of this <$> syntax and *actually* break its usage out into separate functional components within the same file.
Natural hoisting makes this even easier because we don’t have to worry about order.
May 17, 2025 at 4:55 PM
BUILD PLUGIN (1/4)
e.g. Vite/Webpack/etc.
In this approach, I would pre-compile any uses of this <$> syntax and *actually* break its usage out into separate functional components within the same file.
Natural hoisting makes this even easier because we don’t have to worry about order.
e.g. Vite/Webpack/etc.
In this approach, I would pre-compile any uses of this <$> syntax and *actually* break its usage out into separate functional components within the same file.
Natural hoisting makes this even easier because we don’t have to worry about order.
PROXIES
With the proxies approach, instead of passing the hooks themselves to the callback, I would pass a proxy that watches how the hook is used and somehow carries that usage back to the component instance itself, outside the callback.
I’m not sure how difficult (or possible) that is.
With the proxies approach, instead of passing the hooks themselves to the callback, I would pass a proxy that watches how the hook is used and somehow carries that usage back to the component instance itself, outside the callback.
I’m not sure how difficult (or possible) that is.
May 17, 2025 at 4:55 PM
PROXIES
With the proxies approach, instead of passing the hooks themselves to the callback, I would pass a proxy that watches how the hook is used and somehow carries that usage back to the component instance itself, outside the callback.
I’m not sure how difficult (or possible) that is.
With the proxies approach, instead of passing the hooks themselves to the callback, I would pass a proxy that watches how the hook is used and somehow carries that usage back to the component instance itself, outside the callback.
I’m not sure how difficult (or possible) that is.
I think for v1 to actually make sense, I clearly need to change something here to support or align with React’s Rules of Hooks, which most of these appear to break.
I have two defining ideas—
– proxies
– build plugin
I have two defining ideas—
– proxies
– build plugin
May 17, 2025 at 4:55 PM
I think for v1 to actually make sense, I clearly need to change something here to support or align with React’s Rules of Hooks, which most of these appear to break.
I have two defining ideas—
– proxies
– build plugin
I have two defining ideas—
– proxies
– build plugin
Because my implementation goes a bit deeper than those others, I can do some things to optimize usage within the package, like auto-memoization, striving to follow the same patterns as the compiler.
May 17, 2025 at 4:55 PM
Because my implementation goes a bit deeper than those others, I can do some things to optimize usage within the package, like auto-memoization, striving to follow the same patterns as the compiler.
There are countless solutions and packages out there trying to solve this same problem, so it’s definitely a pain point felt in the framework that I think the core team could tackle in an equally or more elegantly.
May 17, 2025 at 4:55 PM
There are countless solutions and packages out there trying to solve this same problem, so it’s definitely a pain point felt in the framework that I think the core team could tackle in an equally or more elegantly.
I’m not as knowledgeable as you in the compiler’s inner workings.
My primary objective here was to tackle this problem with an approach that ensures the hooks are initialized and used in the same render cycle, which they appear to be, but I can see how it might still violate the rules.
My primary objective here was to tackle this problem with an approach that ensures the hooks are initialized and used in the same render cycle, which they appear to be, but I can see how it might still violate the rules.
May 17, 2025 at 4:55 PM
I’m not as knowledgeable as you in the compiler’s inner workings.
My primary objective here was to tackle this problem with an approach that ensures the hooks are initialized and used in the same render cycle, which they appear to be, but I can see how it might still violate the rules.
My primary objective here was to tackle this problem with an approach that ensures the hooks are initialized and used in the same render cycle, which they appear to be, but I can see how it might still violate the rules.
I agree that sticking to what is recommended as best practice should be promoted here.
Thinking through my implementation, it does feel like a pattern that React Compiler could officially support with the proper affordances.
Thinking through my implementation, it does feel like a pattern that React Compiler could officially support with the proper affordances.
May 17, 2025 at 4:55 PM
I agree that sticking to what is recommended as best practice should be promoted here.
Thinking through my implementation, it does feel like a pattern that React Compiler could officially support with the proper affordances.
Thinking through my implementation, it does feel like a pattern that React Compiler could officially support with the proper affordances.
Thanks, Dan! I really appreciate your thoughtful feedback here.
Do you happen to have a concrete example you could share that I could test around for where this would likely break?
My implementation is different than the usual `children()` approach, but I’m sure it hits the same limitations.
Do you happen to have a concrete example you could share that I could test around for where this would likely break?
My implementation is different than the usual `children()` approach, but I’m sure it hits the same limitations.
May 17, 2025 at 4:55 PM
Thanks, Dan! I really appreciate your thoughtful feedback here.
Do you happen to have a concrete example you could share that I could test around for where this would likely break?
My implementation is different than the usual `children()` approach, but I’m sure it hits the same limitations.
Do you happen to have a concrete example you could share that I could test around for where this would likely break?
My implementation is different than the usual `children()` approach, but I’m sure it hits the same limitations.
And if you would rather not discuss it on X, I’m happy to continue that conversation right here in this thread on Bluesky
TY 🙏🏼
TY 🙏🏼
May 17, 2025 at 6:15 AM
And if you would rather not discuss it on X, I’m happy to continue that conversation right here in this thread on Bluesky
TY 🙏🏼
TY 🙏🏼
Here is the most relevant message from Joe Savona over there:
x.com/en_js/status...
The conversation has progressed past that point into a few tangential conversations and DMs, but I think addressing and discussing the concern there would be fitting, both for my package and that article I shared^
x.com/en_js/status...
The conversation has progressed past that point into a few tangential conversations and DMs, but I think addressing and discussing the concern there would be fitting, both for my package and that article I shared^
Joe Savona on X: "@branmcconnell It's great to see experimentation in this space and I'm super hesitant to chime in and ruin the parade. But just a heads up that this does break the Rules of Hooks since it's passing hooks as first-class values, so code using this library won't get compiled by React Compiler." / X
@branmcconnell It's great to see experimentation in this space and I'm super hesitant to chime in and ruin the parade. But just a heads up that this does break the Rules of Hooks since it's passing hooks as first-class values, so code using this library won't get compiled by React Compiler.
x.com
May 17, 2025 at 6:15 AM
Here is the most relevant message from Joe Savona over there:
x.com/en_js/status...
The conversation has progressed past that point into a few tangential conversations and DMs, but I think addressing and discussing the concern there would be fitting, both for my package and that article I shared^
x.com/en_js/status...
The conversation has progressed past that point into a few tangential conversations and DMs, but I think addressing and discussing the concern there would be fitting, both for my package and that article I shared^