I believe this should only be updating the code right?

So those other lines are there to allow users to be able to preserve highlighted lines from GitHub links. Would you like me to remove that capability from this PR?

Oh I didn't realize that. That's interesting. I like the idea actually.

I think that makes sense for the first time it fetches, but not for syncing long term though

Could it work like this?

1. User pastes the link
2. We fetch the code
3. Parse it to get line numbers
4. Remove the line numbers from the URL
5. Add line number highlights and URL (which no longer includes line numbers reference)
6. Then when syncing next time, next week, etc we just sync the code with no line numbers

So we just have it as is, but we dont persist the url with the line numbers. that way it only ever adds the highlights once. I'm just thinking about users that want to sync with a gist they edit, and the line numbers might now always be the same. i'd hate for them to need to add the URL.

Alternatively we could add a checkbox like "preserve line highlights" or something.

What do you think?

Should use a react approach here and either just add a ternary on the component, or use the classnames package.

So unfortunately you can't really set the className on the TextComponent and have it apply the styles to the input by itself (maybe I need to submit a PR for that too lol)

I went ahead and changed it to a ternary within a useEffect. Would you like me to still use the classnames package?

Maybe just make the text red? You could use a

tag directly instead of the help prop. Might need to add something like m-0 p-0 -mt-1 also if it's too low.

The issue with directly manipulating the dom is that react doesn't track those changes so it could bug out when doing a diff (if not today because conditions are right, maybe in 2 years something changes).

Also, for the text, I was thinking about this a bit more. What do you think about:

1. The main panel is labelled "Sync" instead of "GitHub"
2. The inner control title is "GitHub" instead of "Github Repo Link"
3. The help text is "Supports GitHub file links and Gists"
4. The button says "Save" instead of "Fetch Code" and I guess behaves the same

I also think maybe adding the highlights makes it a bit confusing. If the goal is to keep a file in sync (in case they change the Gist, for example) it would update and put any highlights out of place. It might even be worth disabling those features entirely (even disabling editing too actually). What do you think?

1. ignore any line highlisghts entirely (so no need to parse the url at all)
2. At the top of the panel add a short note on the expectations, that this will override any code edits and forcefully sync the file each page load.

Thanks again, and hope this isn't asking too much. It's great so far :P I'm happy to work on it too though.

and hope this isn't asking too much

Not at all! In fact I really appreciate all the time you're taking to instruct me about your preferences! I'm learning quite a bit, of course I want to be respectful of your time too so if you want to take ownership of something to push things along feel free! This is your repository after all 👍

I also think maybe adding the highlights makes it a bit confusing. If the goal is to keep a file in sync (in case they change the Gist, for example) it would update and put any highlights out of place.

Yknow, while working on the other code change around highlights, I'm realizing now that this is really prone to accidental overwrites. If I put myself in the place of the writer/user, I really want things to stay "deterministic". I don't want simply typing into the GitHub textbox to overwrite my changes, I would probably much prefer to only overwrite my code when I click the "Save" button.
Same thing with code highlighting, because now there would be 2 places where highlighting could change.

I would have to agree with the option with removing the features! Apologies for the complications 😅

Hmm, I am having trouble trying to only set the code when the user clicks the "Save" button though. Since I am using the hook at the top of my component it keeps fetching/setting the remote code.

I would probably much prefer to only overwrite my code when I click the "Save" button.

So the question is actually what is the feature, or what problem is this feature solving? I believe we're seeing it a bit differently so let me write out summaries of both and get your opinoin.

1. It's solving the problem of importing code into the page. So instead of copy/pasting the code into the editor, we are giving them a text input and a button to copy/paste the url and fetch it for them. Additionally, they can go and refetch if they press the button again later (e.g. in 6 months). To me this implies the source file will not be changing that often, so the feature would be "to help users import the code"
2. It's solving a problem for users that manage an actively changing gist or file in a repo that they want to keep in sync without much effort. In my head I pictured having 5-6 on a page and they all just sync when the user goes to edit the page (caveat being it requires they edit the page for it to re-sync). So the feature in this case is "to help auto sync with code that is managed elsewhere"

My descriptions may be biased too, but even writing them out it's not super clear that this will be that useful of a feature if it can't auto-sync behind the scenes (like once an hour or something) even when the user is not editing the page. I also hesitate to give a feature that implies it does something it doesn't, if you know what I mean.

If the idea is to provide easy imports (which I'm not against either), I'd almost rather it incorporate the github oath flow and use the GH api to load in recent gists/repos in the sidebar similar to how selecting a theme works (code previews load in and they can press to import).

Since I am using the hook at the top of my component it keeps fetching/setting the remote code.

I can check the code but typically you would use a useEffect and then update the code when the data changes, and you wouldn't fetch the data until a URL existed. So you'd need an intermediary state variable to handle the form input that didnt't feed into swr