Twitter | Search | |
James Long
Finally launched ! Created . Ex-Mozilla.
16,713
Tweets
855
Following
18,817
Followers
Tweets
James Long 2h
Replying to @ryanflorence
Notion has a lot of cool uses of it like this one:
Reply Retweet Like
James Long 2h
Replying to @ryanflorence
Yep, that's true! My `tooltip` is mostly concerned about positioning, the closing and keyboard stuff is controlled by other stuff
Reply Retweet Like
James Long 2h
Replying to @ryanflorence
"modal" as it's usually used then :) At some point I will check out Reach UI as a replacement for much of my low-level UI infrastructure.
Reply Retweet Like
James Long 2h
Replying to @ryanflorence
I have a single `Tooltip` component that works great for all my use cases of dropdowns/popovers. You could probably rip the code apart, but I rarely have to even look at it anymore. Main thing is probably accessibility.
Reply Retweet Like
James Long 2h
Replying to @ryanflorence
Yeah that's a good description. Mine isn't as complex as that one, but it could be. Design-wise I prefer it over modals - Notion is a great example. Keeps context a lot better. I haven't thought through accessibility yet though
Reply Retweet Like
James Long 3h
Replying to @jasonkarns @Farzad_YZ
Ah I see, yeah makes sense
Reply Retweet Like
James Long 3h
Replying to @jasonkarns
I thought you mean building after npm installing your dep but now I think you mean building automatically right before publishing to npm. The latter is valid... building on install sucks (but necessary for native stuff)
Reply Retweet Like
James Long 3h
Replying to @mourner
Yeah, the difference is when you do it. When you make some tweaks, of course you have to rebuild it. Wanting to pull down someone's fork (even just a PR) shouldn't require that. You can add built files, but it's awkward because can't do it on master, makes rebasing harder
Reply Retweet Like
James Long 3h
Replying to @mourner
I haven't tried some ideas I have to solve this, so I could be wrong
Reply Retweet Like
James Long 3h
Replying to @mourner
All of different pros/cons, linking doesn't work sometimes (and requires you first checkout, build, etc, annoying). Sure, we have different experiences and opinions. That's fine! I do think tooling changes the effectiveness of each approach a lot.
Reply Retweet Like
James Long 3h
Replying to @ryanflorence
do you have another component that is similar but for more complex content that can be interacted with?
Reply Retweet Like
James Long 3h
Replying to @ryanflorence
the scrolled container in a special component that creates a "boundary" for the tooltip so it positions & attaches itself to the scrolled element, so it scrolls correctly with anything inside it! Make any sense?
Reply Retweet Like
James Long 3h
Replying to @ryanflorence
I don't have time to try it out yet, but here's a use case I need: by default a "tooltip" (which I use for all kinds of complex overlay things) is statically positioned on top of everything, but that doesn't work if an element can be scrolled. I can wrap...
Reply Retweet Like
James Long 3h
Replying to @mourner
I'm not making this up! From my experience, it's far more friction.
Reply Retweet Like
James Long 3h
Replying to @mourner
You're ignoring the much bigger problem of have to rewrite all your requires which is a show-stopper if you're wanting to try different forks. Forks are awesome, they should be encouraged and need better tooling.
Reply Retweet Like
James Long 4h
Replying to @mourner
The built files don't necessarily even have to reflect the current source code, but could be just the latest stable version (JS libs used to do that a lot before putting frontend libs in npm, so you could just download the lib from github)
Reply Retweet Like
James Long 4h
Replying to @mourner
A couple options, same problem as other things like keeping code formatted with prettier, etc. Different people like different things. A bot works, CI could also add a commit to a PR once it's approved & ready to merge, etc.
Reply Retweet Like
James Long 4h
Replying to @mourner
Every single require has to be rewritten in the form of `require("@<scopename>/foo")`, and rewritten back once you don't need the fork anymore. It's horrible. Built files are fine, just need a better process for them. Don't need to build in PRs, etc
Reply Retweet Like
James Long 4h
Replying to @satya164
I really think we need a much more lightweight process for simply forking a lib and adding a few tweaks here and there over time. Should be as simple as pressing a button and making a few commits here and there, and a quick rebase (via another button) every now and then.
Reply Retweet Like
James Long 4h
Replying to @satya164
I forgot about that, dang. I hate having to publish to npm for many reasons, one being that you usually use scoped packages and it leaks into your program via `require("@jlongster/foo")` instead of `require("foo")`
Reply Retweet Like