<script lang="ts">
import IconBlock from "layout/IconBlock.svelte";
import { fs_thumbnail_url, FSNode } from "lib/FilesystemAPI.svelte";
import TextBlock from "layout/TextBlock.svelte"
import { formatDataVolume, formatDate } from "util/Formatting";

let {
	node,
	open_details,
	children,
}: {
	node: FSNode
	open_details: () => void
	children?: import('svelte').Snippet
} = $props();
</script>

{@render children?.()}

<IconBlock icon_href={fs_thumbnail_url(node.path, 256, 256)}>
	{node.name}<br/>
	<table>
		<tbody>
			<tr>
				<td>Type</td>
				<td>{node.file_type}</td>
			</tr>
			<tr>
				<td>Size</td>
				<td>{formatDataVolume(node.file_size, 3)}</td>
			</tr>
			<tr>
				<td>Upload date</td>
				<td>{formatDate(node.created, true, true, false)}</td>
			</tr>
		</tbody>
	</table>
	<hr/>
	<button class="button_highlight" onclick={() => node.download()}>
		<i class="icon">download</i>
		<span>Download</span>
	</button>
	<button onclick={() => open_details()}>
		<i class="icon">help</i>
		<span>Details</span>
	</button>
</IconBlock>

{#if node.name === ".search_index.zstd"}
	<TextBlock>
		<p>
			Congratulations! You have found the search index. One of the
			filesystem's dirty little secrets.
		</p>
		<p>
			I needed a place to store an index of each user's files so I could
			make them searchable. Now, there are search databases like
			ElasticSearch and such, but that's a lot of work to set up and
			maintain.. Instead I opted to simply put the full path of every file
			in your filesystem in a text file. That's what you're looking at
			here. That can add up to a lot of data, but since the paths usually
			have a lot of repetitive elements it compresses incredibly well.
			You'd be hard-pressed to grow this index over even 1 MB. Honestly,
			this search system is incredibly efficient, I'd be surprised if
			ElasticSearch could even match it.
		</p>
		<p>
			This file is updated 10 minutes after the last time you modify a
			file on your filesystem. So if you're constantly uploading and
			deleting files your search index might never update and you will be
			left with stale search results.
		</p>
		<p>
			If you delete this file then search will stop working until the file
			is regenerated 10 minutes later. If you replace this file with a
			different file then that file will be overwritten 10 minutes later.
			And if you replace this file with a directory with the same name
			then search will stop working completely until you delete the
			directory (yes, I tested this case).
		</p>
		<p>
			Each time you type a search term in the search dialog this file gets
			decompressed and searched on the fly. There is no trickery here, the
			file simply gets read line by line. Modern CPUs are incredibly good
			at searching for text. I benchmarked it once, I don't remember the
			exact numbers but it was somewhere along the lines of one gigabyte
			of text per second. Fast enough to be unnoticeable even if you have
			millions of files in your filesystem.
		</p>
	</TextBlock>
{/if}

<style>
table {
	width: auto;
}
td {
	padding: 0;
	padding-right: 1em;
}
.icon {
	display: inline-block;
	vertical-align: middle;
}
</style>
