Implements search based on SurrealDB

[emmanuel-keller]

Implements the search backed by SurrealDB :)

git checkout emmanuel/surreal-search
pnpm run start

[netlify]

✅ Deploy Preview for surrealdb-docs ready!

Name	Link
🔨 Latest commit	2597839
🔍 Latest deploy log	https://app.netlify.com/sites/surrealdb-docs/deploys/653159f6d292f900086febf2
😎 Deploy Preview	https://deploy-preview-24--surrealdb-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[dimitrianoudi]

Instead of using .map followed by .reduce, you can use a single .reduce to calculate the total length of offsets:

function findBiggestOffsets(offsets: Offset[]): number {
    return offsets.reduce((sum, { s, e }) => sum + (e - s), 0);
}

[dimitrianoudi]

Instead of Object.entries(doc.offsets).sort(...)[0] to get the biggest offset, you could use a loop to find the largest without sorting, which would reduce the operation from O(n log n) to O(n). Sorting just to get the maximum value isn't efficient.

[dimitrianoudi]

let maxOffsetSize = -1;
let linenumber = null;
let offsets = null;

for (const [line, off] of Object.entries(doc.offsets)) {
    const currentOffsetSize = findBiggestOffsets(off);
    if (currentOffsetSize > maxOffsetSize) {
        maxOffsetSize = currentOffsetSize;
        linenumber = line;
        offsets = off;
    }
}

This above loop iterates over each entry of doc.offsets just once, computes the size of the offsets, and keeps track of the largest value seen so far. This is a direct O(n) operation, which is slightly more efficient than the O(n log n) operation from sorting, especially for large numbers of offsets.

[dimitrianoudi]

Just out of interest, can we check that the server hosting 'https://blog-db.surrealdb.com/sql' is using compression like gzip for responses, which reduces the amount of data transmitted over the network?

[emmanuel-keller]

@kearfy @sgirones

[emmanuel-keller]

It is currently not the case. That would for sure be an great improvement

[dimitrianoudi]

Ref's Usage:
dialogRef is being used in the handleChange function, but it doesn't seem to be actually utilised. This makes it unnecessary to include it in the dependency array of the useCallback.
The same applies to the useEffect hook, which means the dialogRef dependency can be omitted entirely from both hooks.

[dimitrianoudi]

It's generally recommended to use the strict equality (===) instead of loose equality (==). In the conditional rendering section, you've used keywords == '', which should ideally be keywords === ''.

[dimitrianoudi]

remove console.log

[emmanuel-keller]

Oops!

[dimitrianoudi]

If the search API (search function) can be potentially slow or rate-limited, it would be a good idea to debounce the input changes so that not every keystroke triggers an API call.

function debounce(func, delay) {
  let inDebounce;

  return function(...args) {
    const context = this;
    clearTimeout(inDebounce);
    inDebounce = setTimeout(() => func.apply(context, args), delay);
  };
}

const debouncedSearch = useCallback(debounce(async (value) => {
    if (!value) {
        setResults([]);
        setKeywords('');
    } else if (value !== keywords) {
        setKeywords(value);
        try {
            let res = await search(value);
            console.log(res);
            setResults(res);
        } catch (err) {
            console.error(err);
        }
    }
}, 300), []); // Here, 300ms is the delay, we can re-adjust that if needed.

const handleChange = (value) => {
    debouncedSearch(value);
};

[emmanuel-keller]

Great review @dimitrianoudi! Everything's been applied

[dimitrianoudi]

It looks great, although it misses the Lodash dependancy.
Can you please do a:
pnpm install lodash
then commit the package.json and pnpm-lock.yaml and that should do!