Part of filter and preference feature

[khamkarsuraj]

Related issue This issue is sub-task of issue #217.

Description In #217, the enhancement request was to implement filtering and tracking user preferences. But making all these changes in a single patch will causes dependency issues in future. To avoid this and isolate task so that we can distribute within multiple people, I am creating this task. This task will be closed once done with below sub-tasks.

Filtering Options

• [x] Job Type
• [x] Experience Level
• [x] Location
• [ ] Status

Preference Options

• [ ] Position already filled
• [ ] Disinterest in position
• [ ] Interested position

If you are new to this task please read Community Guidlines and refer #224 which is proposal for task.

[khamkarsuraj]

@Nayaker, Are you fine with creating sub-tasks like this to implementation of feature?

[NayakPenguin]

Yeah sure, I will 👍

[NayakPenguin]

@shadow-ryu have a look on these

[shadow-ryu]

okay

[shadow-ryu]

I've completed the implementation location filtering, but I could use assistance with the status filter. Currently, there is no backend support for features such as 'like,' etc. Can you help with this? @Nayaker @khamkarsuraj

[khamkarsuraj]

@shadow-ryu, will you link your PR with this issue so that I could have look at changes?

[NayakPenguin]

I've completed the implementation location filtering, but I could use assistance with the status filter. Currently, there is no backend support for features such as 'like,' etc. Can you help with this? @Nayaker @khamkarsuraj

I think you should store them on the local storage for each user.

[shadow-ryu]

@shadow-ryu, will you link your PR with this issue so that I could have look at changes?

Created a pr for the same link. Let me know if any changes are required

[shadow-ryu]

I've completed the implementation location filtering, but I could use assistance with the status filter. Currently, there is no backend support for features such as 'like,' etc. Can you help with this? @Nayaker @khamkarsuraj

I think you should store them on the local storage for each user.

will Look into it

[khamkarsuraj]

I've completed the implementation location filtering, but I could use assistance with the status filter. Currently, there is no backend support for features such as 'like,' etc. Can you help with this? @Nayaker @khamkarsuraj

I think you should store them on the local storage for each user.

I think storing information about like, dislike into localStorage is not that good idea. Because we might have 100 of records listed there and rendering webpage every time with that many local variable might slow downs the application. We should think something else for that.

@Nayaker @shadow-ryu

[NayakPenguin]

Presently, Algolisted imposes constraints on the number of API calls we can make, prompting me to store data locally. Although this approach may introduce a slight slowdown to the application, the impact is expected to be relatively minor. However, I am open to exploring alternative methods that could mitigate this issue without relying heavily on API calls. If you have any suggestions or better approaches, I am eager to hear and discuss them.

@khamkarsuraj @shadow-ryu

[shadow-ryu]

If you want to use client to save we can try storing it in session storage / IndexedDB

[NayakPenguin]

If you want to use client to save we can try storing it in session storage / IndexedDB

Session storage is similar to local storage, but with a shorter lifespan. It is suitable for temporary data that should be available only during a browser session.

I don't have much knowledge about IndexedDB, can you mention the advantages and disadvantages?

[shadow-ryu]

As much I know IndexedDB is more suitable for complex data storage, querying, and indexing and its long term storage.

[NayakPenguin]

Any thoughts you'd like to share, @khamkarsuraj?

[khamkarsuraj]

As much I know IndexedDB is more suitable for complex data storage, querying, and indexing and its long term storage.

Using IndexDB causes more costly operations, and I do not favor that. Though open for discussion.

Any thoughts you'd like to share, @khamkarsuraj?

Using localStorage will solve our problem, sessionStorage and Cookies are the options, too, but these options come with expiration. Currently, when we are not in the position to give a callback to the backend server, using localStorage does make sense. But there are some corner cases we should take into consideration. For instance, If the user wants to clear all preferences, we should implement one button that will remove all the localStorage data relevant to preferences, if the browser doesn't find any localStorage data for preferences while loading the page for the first time then we should also pop-up some appropriate message etc. We will encounter many such corner cases while writing code.

@Nayaker @shadow-ryu

[NayakPenguin]

Indeed, there are indeed specific scenarios that need to be addressed when opting for localStorage. It's essential to handle these situations individually. I've encountered similar challenges in other sections of our application, as exemplified in pages like https://algolisted.com/coding-sheets/striver-sde-sheet. It's crucial to proactively address issues such as clearing all preferences, providing a mechanism to remove relevant localStorage data, and handling cases where no localStorage data for preferences is found during the initial page load.

@khamkarsuraj @shadow-ryu

[khamkarsuraj]

Sounds good. We have our approach ready then. @shadow-ryu Would you like to work on preferences?

[shadow-ryu]

@khamkarsuraj , I would love to taken on the task, but currently, my schedule is quite packed. If someone else is interested, they are more than welcome to take it on. I anticipate being available to address it in a day or two. If it's acceptable, I would like to recommend my friend for this task. @rohancodex

[NayakPenguin]

@khamkarsuraj , I would love to taken on the task, but currently, my schedule is quite packed. If someone else is interested, they are more than welcome to take it on. I anticipate being available to address it in a day or two. If it's acceptable, I would like to recommend my friend for this task. @rohancodex

@khamkarsuraj ??

[khamkarsuraj]

@khamkarsuraj ??

Waiting for reply from @rohancodex otherwise I am ready to work on this task.

[rohanattorinit]

@khamkarsuraj I'll take up this task. Thanks!

[rohancodex]

@Nayaker Is there any design for the colors for the like, filled, not-interested icon interactions?

[NayakPenguin]

@Nayaker Is there any design for the colors for the like, filled, not-interested icon interactions?

colors are not planned as of now, but try to keep the color structure similar to other pages like https://algolisted.com/coding-sheets/striver-sde-sheet

[khamkarsuraj]

Hey @rohancodex, How is it going for you?

[rohanattorinit]

Hey @khamkarsuraj, was a busy week at work. I've started working on it. Should be done with the status filter by tonight.

[rohancodex]

Hey @khamkarsuraj @Nayaker , is there no unique field for the items of the opportunity table? If so should I maybe combine 2 fields to make a unique field?

​{ contributor: "Atanu nayak", date: "2023-11-22T18:30:00.000Z", job_link: "https://careers.adobe.com/us/en/job/ADOBUSR141934EXTERNALENUS/2024-Intern-Machine-Learning-Engineer?utm_medium=phenom-feeds&source=LinkedIn&utm_source=linkedin", job_title: "Adobe - ML", location: "India", magic_filter: "yes", role: "Machine leaning", salary_high: 12, salary_low: 9, source: "https://www.google.com/search?q=long_param", type: "FTE", years_exp: "Fresher"}

[khamkarsuraj]

Hello @rohancodex, We already have a unique URL for every JSON record, but there are better ideas than storing this big string in localStorage. I would have used this URL to create a unique identifier using Hashing or something and held it in localStorage. This unique identifier can then be used as per the user's preference, like, dislike, etc. First, store a unique identifier for each record in browser storage while loading the page. Secondly, whenever the user clicks on any of the buttons, get its URL, convert it into a unique identifier and check with already stored unique identifiers; once found, mark it with the respective operation. Take your time, no worries.

@Nayaker Thoughts?

[rohanattorinit]

I was thinking something like this might be more performant rather than hashing and getting back the string every time:

[NayakPenguin]

I was thinking something like this might be more performant rather than hashing and getting back the string every time:

The regex may need adjustment since the link might not consistently have /job. Besides that, I believe it is good.

Additionally, regarding hashing, @shadow-ryu seemed to imply a concept similar to this unique key. However, I propose calculating it initially during or before mapping to facilitate direct matching with localStorage. This approach eliminates the need to convert hashing back to a URL later on.

[NayakPenguin]

@rohanattorinit updates?

[NayakPenguin]

@khamkarsuraj can you please complete this issue?