click-to-component
click-to-component copied to clipboard
Support for OpenFile to Intellij
🦋 Changeset detected
Latest commit: 75ed249a3ae0da3eeb04fe1a9845c415318500b0
The changes in this PR will be included in the next version bump.
This PR includes changesets to release 1 package
| Name | Type |
|---|---|
| click-to-react-component | Patch |
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
add intellij to export type Editor = 'vscode' | 'vscode-insiders' please
jetbrains IDEs partially support URL handling, like this:
webstorm://open?file=/Path/To/File.tsx&line=4&column=5
The following schemes are supported:
'webstorm',
'phpstorm', // also occupies 'idea'
'pycharm',
'x-mine', // rubymine
'goland',
'idea', // may conflict with phpstorm
Unfortunately this only works for macos.
But I still think it might be faster than opening via http://localhost:63342
Perhaps it is worth doing a check on the operating system and doing two ways? What do you think?
jetbrains IDEs partially support URL handling, like this:
webstorm://open?file=/Path/To/File.tsx&line=4&column=5The following schemes are supported:
'webstorm', 'phpstorm', // also occupies 'idea' 'pycharm', 'x-mine', // rubymine 'goland', 'idea', // may conflict with phpstormUnfortunately this only works for macos.
I tried this methos but jetbrains got an error: "Unsupported protocol" regression for URI handler. There are unresolved issues like https://youtrack.jetbrains.com/issue/IDEA-284396
The safest method remains http://localhost:63342, it is fast and simple. What do you think ?
The safest method remains http://localhost:63342, it is fast and simple. What do you think ?
Just noticed that URL Handling works all the time, even when the IDE is closed, it'll then open it. The localhost server is only active when the IDE is open (which should be the case most of the time)
The localhost server is only active when the IDE is open (which should be the case most of the time)
I think it makes sense to add this to the documentation.
=======
We can implement both methods and describe their differences in the documentation. A consumer will choose a desired option. There is not even a coincidence of the names of the editors.
It seems to me that this PR does its job well.
I'd like to add schema support for specific IDEs later (if no one gets ahead of me).
I added the possibility to change the default editor in the context menu. It stores the value in localstorage, so the project team can have different IDE preferences. What do you think ?


Thank you for everyone! I'm pretty glad to this PR tractions as a WebStorm user!
I added the possibility to change the default editor in the context menu. It stores the value in localstorage, so the project team can have different IDE preferences. What do you think ?
Not a bad idea. Could we somehow also create a more persistent solution to this? While developing I often clear the whole application data to reset something or test a fresh state. This would always reset this, right? I only have two idea which are both not the best but maybe someone else has better ones.
- Environment Variable
This could be tricky, because IIRC CRA only allows env vars prefixed with
REACT_APP_, but this would probably not work with Next.js or so out of the box (as Next.js needs to have env's specifically passed and then they are underpublicRuntimeConfigand notprocess.env). - Read from window object
This ones probably a bit dirty / hacky but we could define a property (like
window.CLICK_TO_COMPONENT_EDITOR) which users could set via UserScripts or some Custom JS Injector.
The order could be smth like "localStorage > window > environment" so localStorage would override window and env and window would take presence before environment if localStorage has nothing stored. Does that make sense to you?
I added the possibility to change the default editor in the context menu. It stores the value in localstorage, so the project team can have different IDE preferences. What do you think ?
Great idea. But sounds like a separate PR. I'm afraid adding new features (which are yet to be discussed) will slow down the approve of this PR.
@dunklesToast another dirty thought is to somehow use GET parameters. For example, take initial value from there and put it in LS or window.
Great idea. But sounds like a separate PR. I'm afraid adding new features (which are yet to be discussed) will slow down the approve of this PR.
You're right ! I revert code to change the default editor in the context menu. I will make a separate PR.
@ericclemmons I'm waiting for your instructions if you have any, thanks
@ericclemmons hi! any updates here?
Any update on this? Would love to have it, might just have to check out this PR if it isn't going to be merged.
@zaideygrek Looks like this project is abandoned. We're gonna have to use a fork to have this feature implemented. :/
@ericclemmons per chance, could you please clarify if you still plan on supporting this repo? thank you!
I struggled to get this working as a Chrome extension.
That would be the best way for it to work without code changes and support per-machine IDEs.
Paid dev is taking precedence, so if anyone wants to DM me about project rates, reach out via Twitter 🙏🏻
On Thu, Oct 6, 2022 at 3:52 PM Mika Melikyan @.***> wrote:
@zaideygrek https://github.com/zaideygrek Looks like this project is abandoned. We're gonna have to use a fork to have this feature implemented. :/
@ericclemmons https://github.com/ericclemmons per chance, could you please clarify if you still plan on supporting this repo? thank you!
— Reply to this email directly, view it on GitHub https://github.com/ericclemmons/click-to-component/pull/35#issuecomment-1270680040, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAADWTV4YNBN3HKCEEYB3GTWB43ZZANCNFSM5UQ5GIPA . You are receiving this because you were mentioned.Message ID: @.***>
-- Sent from Gmail Mobile
What do you think about this chrome extension locatorJs ?
I still think this is a fantastic solution and could actually be turned into a big product with more features, but as-is it's awesome doing its job!
I've tried LocatorJs and it's not nearly as intuitive as click-to-component.
Concerning the IntelliJ support that this PR addresses, I've tested with WebStorm and works like a charm ✨
Please consider merging this :))
I added @dartess, @mmelikyan , & @zaideygrek collaborators.
Previously, this project was supported by Stripe but is not any longer.
about the comment above: sounds good, I think I can spend a little time on it. but I don't have much experience with versioning support and stuff around releases.
@ericclemmons do you still own and release new versions? If so, can you add an available CONTRIBUTING.md to the project?
about this PR: @zaideygrek will you have time to update this PR or will I pick up this task?
Sorry I don't have time to clean the code and continue this PR.