Part of filter and preference feature about algolisted HOT 32 OPEN

@khamkarsuraj ??

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

from algolisted.

@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

from algolisted.

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

from algolisted.

@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

from algolisted.

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

from algolisted.

Yeah sure, I will 👍

from algolisted.

@shadow-ryu have a look on these

from algolisted.

okay

from algolisted.

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

from algolisted.

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

from algolisted.

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.

from algolisted.

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

from algolisted.

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

from algolisted.

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

from algolisted.

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

from algolisted.

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?

from algolisted.

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

from algolisted.

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

from algolisted.

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

from algolisted.

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

from algolisted.

@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

from algolisted.

@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 ??

from algolisted.

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

from algolisted.

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

from algolisted.

Hey @rohancodex,
How is it going for you?

from algolisted.

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

from algolisted.

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"}

from algolisted.

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?

from algolisted.

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

from algolisted.

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.

from algolisted.

@rohanattorinit updates?

from algolisted.

@khamkarsuraj can you please complete this issue?

from algolisted.