Publishing First Beta & Refactoring The Code
We figured it was time to publish a first beta of our extension to VSCODE marketplace.
We made some little adjustments like renaming some variables, for more readable code, and fixed a few major bugs, and then we published it using this tutorial.
You can find our extension on this link.
*A big bug we had was that the last hover panel continude to show when hovering on defferent lines that are not a URL. Our problem was fixed by updating the current URL variable to UNDEFINED and the markdown string to an empty string, like so:
Now that we published our first working extension, we wanted to focus more on the code and the design.
Firstly, we decided it would be smarter to extract the relevant line and check what is it's format rather then what we made so far- which is to send the whole document to each extraction function.
We created a new function called "extractCurrentLine" which does the following:
1. The function receives the document text string and the current cursor position
2. It makes two substrings: one substring from the beginning of the text string to the current position (we call it the left substring), and a second substring from the current position to the end of the text string (we call it the right substring) - red box.
3. Then, we search for the last ' or " character in the left substring and the first ' or " character in the right substring.
4. If we found two matching quotes, we check to see if between these two "barriers" there are a new line or tab characters. If there are any, it's not valid. If there aren't, it might be a potential URL- orange box.
5. If we haven't found two matching "barriers", we will take the closest whitespace from each side (the last whitespace from the left substring and the first whitespace from the right substring)- green box.
* Also we dealt some edge cases when the potential URL is the first or the last line in the file - purple box.
Firstly, we decided it would be smarter to extract the relevant line and check what is it's format rather then what we made so far- which is to send the whole document to each extraction function.
We created a new function called "extractCurrentLine" which does the following:
1. The function receives the document text string and the current cursor position
2. It makes two substrings: one substring from the beginning of the text string to the current position (we call it the left substring), and a second substring from the current position to the end of the text string (we call it the right substring) - red box.
3. Then, we search for the last ' or " character in the left substring and the first ' or " character in the right substring.
4. If we found two matching quotes, we check to see if between these two "barriers" there are a new line or tab characters. If there are any, it's not valid. If there aren't, it might be a potential URL- orange box.
5. If we haven't found two matching "barriers", we will take the closest whitespace from each side (the last whitespace from the left substring and the first whitespace from the right substring)- green box.
* Also we dealt some edge cases when the potential URL is the first or the last line in the file - purple box.
After that, we figured we don't need the "getUrlStart" function, because our new function deals with that.
We also updated the (currently) three extraction functions ("extractUrlByExtension","extractUrlByYouTube","extractCssUrl") to an easier validation functions, and changed their names accordingly ("validateIfImageUrl","validateIfYouTubeUrl","validateIfCssUrl").
In addition, we renamed the "getUrlStart" functiont to "getPotentialUrl".
BEFORE:
AFTER:
And the validation functions:
Next, we wanted to make the option to support relative paths.
We already support relative paths in the CSS format, so we took the "logic" of the "openCssFile" function to a separate function.
This function is quite similar to the "openCssFile" function, with the addition of returning the input URL if we haven't altered the current explicit path.
Now the "openCssFile" function looks like this:
We also called this function ("makeExplicitPathFromRelative") from the "getLocalImageMarkdownString" function, so it will support relative paths as well:
Next things for us to do:
1. Work more on the design
2. Make a tutorial of how to implement other format support (after the design)
3. Extend support as much as possible (we yet to finish supporting css and relative paths)
THIS IS WHAT IT LOOKS LIKE SO FAR:
Comments
Post a Comment