-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support custom rules #20
Conversation
Require default Linkify in tests
7f11186
to
d8b7ac4
Compare
… instance add ;s syntax cleanup
One issue i'm noticing is that i can't easily merge custom global handlers with instance handlers, because linkify-it doesn't expose them. I could read its internal schemas map (https://github.com/markdown-it/linkify-it/blob/master/index.js#L396) but it's a private property. |
@olslash What about instead of having a global instance of |
That's a good idea. My only concern is that as we try to support the rest of the LinkifyIt customizations (custom TLDs and the fuzzy* options), we end up duplicating more and more of that library's logic. For example, it would be nice to keep the same chained API that they use to avoid having two sets of docs, but then react-linkify has to mirror their code. It's simple code, but not entirely trivial. That's why I had the thought of using their private Anyway for now I'll write the custom handler code from the direction you suggested, and we can see how it looks. edit: i think i can get around duplicating anything, now that I think about it. |
* upstream/master: Update dist Add support for passing wrapping span's className in as prop. Default to Linkify. Upgrade babel-jest, jest-cli, and jest Require default Linkify in tests
I took a stab at it -- let me know what you think and I'll write docs if it's ok |
e7667b8
to
a861b0a
Compare
a861b0a
to
35512d0
Compare
} | ||
|
||
// add instance customizations | ||
(handlers || []).forEach((handler) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
handlers
defaults to []
, so handlers.forEach(...);
should be sufficient.
Looks good for the most part and great job mirroring the linkify-it api. A concern that I thought of now is that this would make the Linkify component coupled with the linkify-it library. I'm wondering if this is the best way to go especially for cases where some other library has other benefits. One idea to decouple the two is to have the Linkify component take a |
That definitely leads to a more generic component -- I just wonder if it's at the cost of ease-of-use, and if supporting multiple matching libraries is really an important goal, considering how much linkify-it can be customized. With the prop approach, I have to manage a linkify-it instance in each place I want to use the component. Also, even if I wanted to use a custom matching library, linkify-it would still be a dependency of the react-linkify so I'm not saving much there. Possibly a good middle ground is to combine the getMatches prop + the possibility of using a custom global matcher. For my project, I would use a linkify-it instance as my global matcher with my global handlers set. For someone else, it might be some other library. |
As an effort to make this more generic, you'll have the flexibility to support this in const matchDecorator = (text) => {
// Implement your matching logic here to using your customized instance of LinkifyIt
};
<Linkify matchDecorator={matchDecorator}>
...
</Linkify>
Any feedback is appreciated. |
This gives the ability to add custom linkify-it handlers to individual react-linkify instances through the
handlers
prop. Additionally, i exposed the linkify-it singleton to enable global customization.I also cherry-picked the test-suite updates from #19.
Fixes #10