All solutions

What are you most proud of, and what would you do differently next time?

What I am proud of:

• The templates (mixins) created with SCSS, particularly the ones to style button themes and the one to create the classes for Vue.js' Transition classes. It is a cool feature but it kind of becomes a pain to write after a while.

• The use of slots to maintain scalability (ModalBase component); clean code & readability (CommentItemLayout component); and to avoid repetition (ButtonWithLoading component)

• The first clear and effective use of Grid layout, personally speaking

• Dynamic load of SVGs using Vue 3's defineAsyncComponent and Vite's SVG loader (This resource is GOLD)

• Toasts feature created from scratch, and working surprisingly well

• The "Backend" using local storage, the composable useFakeStorage, which (kind of) simulates a database and a RESTful API behavior. I'm kind of proud of using the Promises well to simulate the asynchronous actions and the setTimeout to simulate latency. That was pretty cool, even if not being the prettiest and most performant of codes.

What I'd do differently: The "Backend" again. At the same time that I'm proud of doing so, perhaps could be faster and less difficult if I just created some instance of MongoDB or whatever.

What challenges did you encounter, and how did you overcome them?

I had lots of challenges since I tried to achieve too much stuff, but the most painful one was to type the results from the "fake API".

My approach used the try / catch blocks to handle errors, as I always did with old plain JS and with PHP, but I didn't know how it could be a pain with TS. I kind of handled with the help of some articles like this one, but I still need some improvements.

What specific areas of your project would you like help with?

First of all, please have fun playing with the layout. It was pretty fun to code and I am quite satisfied with the outcome. Then as always, any feedback is welcome.

But the most important thing(s) that I want help:

[TypeScript] Do you recommend some good resources or do you have some tips for typing error handling in catch block? And what about API responses? This would help me a lot

[Tests] I started some testing in project with vitest + vue-test-utils, but I didn't have the patience to write every test case I was thinking of, and one of the main reasons that I stopped trying is that I was spending too much time looking for references and usage examples in their documentation (I'm kind of new to automated tests).So if you may recommend any resources, cheatsheet, alternative documentation or something like that, I would greatly appreciate it

What are you most proud of, and what would you do differently next time?

Somehow this time I had less Type errors during development and this is quite an enjoyable remark.

I am satisfied with the structure of the logic too, with the composables separated by their respective roles:

• one to render map with Leaflet.js;
• one to communicate with the Geolocation API;
• one to handle localStorage to look for past results);

and binding them together later

One of the focus of the solution is to "save" some usage of the API requests since it is limited to 1000 requests. To do so, I pretty much save every pair search/IP result in a Map on localStorage. Possibly not the most memory-wise-performant, so this is a part that I would do differently next time. Perhaps saving only needed properties, and a simple array to processo to a Map instead of saving the key + entry pair

What challenges did you encounter, and how did you overcome them?

The Leaflet.js rendering, my goodness... for some reason the package from npm don't import the CSS or something like that and kind of wasn't working at all until I added the stylesheet manually at index.html. After that, Leaflet kind of started to work more smoothly.

Another challenge that I had was to make requests and rendering reactive to the change of the states. The initial idea was to create a reactive object with ipAddress or domain, and fetch the API when that object changes. But after some tests, I scratched that approach because:

1. It overcomplicates the architecture;
2. It was more risky to waste usage of requests to the API.

The watch of the lat+lng change to render the updated map was somehow challenging too, not sure why. But after some attempts and changes in the watch function and the useLeaflet composable, it worked

What specific areas of your project would you like help with?

There are some points:

• [TypeScript] The declaration of types at src/types/GeolocationAPI.d.ts and their usage at src/stores/ip-tracking.ts and src/composables/useGeolocationAPI.ts. Are they ok or it could be better in some another way?
• [TypeScript] I'd love some feedback about the use of generics at src/composables/useCachedResponses.ts
• [Pinia] This is the first time I use Pinia for anything, so I'm not sure if it is organized enough since it is kind different with the Vuex
• [SCSS] If there are some alternative ways to apply the styles inside the components, I'd like to hear
• [Logic] The overall feedback of the logic, if possible. What you'd do different, what could be better, I'd like to know

What are you most proud of, and what would you do differently next time?

Perhaps the use of composable to extract the filters based on the entries and to handle the local storage. But in some aspects the solution was overcomplicated and I feel kind of uncomfortable by including so many properties in the value returned by the composable. I'm not sure if that was a good practice, probably not

What challenges did you encounter, and how did you overcome them?

The TS errors in the IDE and the logic inside the tags composable. I searched for ways to solve the issues by altering the configuration of the project; and as for the logic, I tried to simplify the initial logic using JS data structures like Set and Map

What specific areas of your project would you like help with?

The logic in the useTagFilter. I created an internal Set where each filter applied is added as a string containing the property name and value (for example, 'tools-Vue'), because if the entries are created by the user typing the values, it is possible that 'Vue' could be added as a language instead of tool or something like that. That said, I return a mapped array removing the key from the string.

I see some problems with that approach:

• I maintained the list filtering logic (the function isResult()) inside the composable
• Too many items on the object returned by the composable
• In the CurrentFilters.vue component, there's no way to know from which property that value is, and that's why I created a keysByValue map. But I feel that it was pretty much unnecessary and waste of memory
• In localStorage, the full joined string is saved, ie. tools-React,tools-Vue,contract-Full Time for example. Saving only the values would be much more functional, but if I do so, the problem is to know from which property that value is

I wanted some feedbacks or insights about that logic, because while I am happy that I finished it and it is functional, I can see that there are bunch of flaws and I feel this is not a optimal approach