Great video once again! A good follow-up video would be to cover the same functionality but instead of doing search already loaded records, it would be up against a REST API with a filter. Possibly with a debounce logic.
That's exactly what I expected this video to be about, I believe this scenario is more common. @@Huntabyte please consider making a video relevant to this topic, you are the only youtuber out there that's so easy to understand and it would be super useful for those of us who are getting started with svelte and sveltekit.
Beautiful! I appreciate how beginner friendly your videos are and help to create real-world functionality. Also great to focus on js first and adding ts later. Thank you!
Awesome video! One idea, Why not make searchTerm a writable store, and make searchStore a derived store that recomputes filtered values based on searchTerm? Basically eliminate the need for manual subscription
Super video. And great that you add the typescript boilerplate last. It makes it so much easier to follow. (Not a fan of typescript. Using it, but not a fan. At all)
@@Huntabyte while true it still makes code look busy. Lots of "annotations" that distracts from the real logic. I kinda like jsdocs as a lightweight approach. Keeping it in comments can make it easier to keep out of sight. Funny enough, I come from c# so go figure 😏
If you are already "pre-computing" the searchTerm property on each product ahead of time, why not convert it to lower case at that point? Instead, you do a .toLowerCase() each time the search term updates, causing a whole bunch of extra work.
Excellent instructional video! How can additional filters be incorporated into the application, appearing as additional buttons? For instance, when clicking the button labeled "laptops," only laptop-related items would be displayed, making it easy to locate specific items within the laptops category.
Nice, tutorial! It would be cool to see you do this same thing using Runes from Svelte 5 so we could see the difference in the amount of work that has to be done.
Real Noice, I was using the reactive $: inside the component and filtering it out there, basically what you did in the store mine was in the component it self, somehow yours seems cleaner but i am too lazy to update mine 😁
can you explain why a store is useful here vs. a hook? We aren’t using these functions, stores, or filter values anywhere else or across cross components or pages. Just curious on the choice to use a store. Thanks!
@@Huntabyte ahhh ok got it. I do like this for something like that. Another good use case I think would be selecting and filtering items across pagination. Thanks for the video and response! I’m learning Svelte right now for my side business and it has been a blast. Your vid’s help a lot!
Although I like the video. The reason this is working is because the searchHandler is modifying on real time the reference of the object the store is located. No Svelte functionality here and the reason reactivity is working is because Svelte actually deeply watches changes on the object but you should not rely on that. If this was done with primitive values this will never work. I would have created instead a second derived store with data filtered based on a search term and then this is the subscribed store in the results panel. But overall is great
Hey thanks for that feedback, if you have discord or could send here - would you mind linking a REPL with an example of this, I’d greatly appreciate it! There’s always a few different ways to accomplish the same thing and I’m always looking for the best ways!
I was about to reply with the same idea. Since the handler is in implemented in your search file it also doesn't make sense to require the consumer to link this up. The derived store would keep this in the same place and give you the option to have multiple derived stores that can be subbed to depending on if you wanted to provide different filter algorithms. e.g. includesSearchResults, fuzzySearchResults, etc...
@Huntabyte I made a simplistic example with all inside page.svelte in 9 lines. But I can give you also all in one single store function stackblitz /edit/github-tnt8vu?file=src/routes/+page.svelte (beware the missing domain)
Wanna point out that you wouldn't do this in a page.svelte file normally, but rather the page.js or page.server.js file. You don't typically execute functional logic on the view itself.
Wouldn't that require a roundtrip to the server every time though? If you already have all your data loaded and the collection isn't that large client side filtering is probably the fastest way to handle it. But fair to say that those cases are rarer than cases where you're filtering from a DB or third party API
Yeah, this video isn't covering how to search via a 'search' endpoint - but moreso a way to filter the already loaded data. There are multiple ways to accomplish the same thing, including an even simpler way then I demonstrated here.
