@torpor/build 0.4.14 → 1.0.1

package/src/nav/navigate.ts

@@ -1,164 +0,0 @@
-import { clearLayoutSlot, fillLayoutSlot, hydrate } from "@torpor/view";
-import { type Component, type SlotRender } from "@torpor/view";
-import { mount } from "@torpor/view";
-import $page from "../state/$page";
-import client from "../state/client";
-import type LayoutPath from "../types/LayoutPath";
-import type PageEndPoint from "../types/PageEndPoint";
-import type PageServerEndPoint from "../types/PageServerEndPoint";
-import formSubmit from "./formSubmit";
-import loadData from "./loadData";
-
-// @ts-ignore
-export default async function navigate(url: URL, withHydration = false): Promise<boolean> {
-	let parent = document.getElementById("app");
-	if (!parent) {
-		// TODO: 500
-		console.log("500");
-		return false;
-	}
-
-	const path = url.pathname;
-	const query = url.searchParams;
-
-	//console.log(`navigating to '${path}'${query.size ? ` with ${query}` : ""}`);
-
-	const route = client.router.match(path, query);
-	if (!route) {
-		// TODO: 404
-		console.log("404");
-		return false;
-	}
-
-	// Update $page before building the components
-	$page.url = url;
-	if (path.endsWith("/_error")) {
-		$page.status = parseInt(query.get("status") ?? "404");
-		$page.error = { message: query.get("message") ?? "" };
-		// Make it look a bit classier by removing the query
-		window.history.replaceState({}, "", url.toString().split("?")[0]);
-	} else {
-		$page.status = 200;
-	}
-	const handler = route.handler;
-	const params = route.params || {};
-
-	// There must be a client endpoint with a component
-	const clientEndPoint: PageEndPoint | undefined = (await handler.endPoint()).default;
-	if (!clientEndPoint?.component) {
-		// TODO: 404
-		console.log("404");
-		return false;
-	}
-
-	// There may be a server endpoint
-	const serverEndPoint: PageServerEndPoint | undefined =
-		handler.serverEndPoint && (await handler.serverEndPoint())?.default;
-
-	let newLayoutStack: LayoutPath[] = [];
-
-	// Pass the data into $props
-	// TODO: Don't load if this is the first time -- it should have been passed
-	// to us, somehow...
-	const data = await loadData(
-		handler,
-		params,
-		path,
-		query,
-		newLayoutStack,
-		clientEndPoint,
-		serverEndPoint,
-	);
-	// We may have form data in a hidden input -- not sure if this is the best
-	// way to do it
-	let formInput = document.getElementById("t-form-data") as HTMLInputElement;
-	let form: Record<string, string> | undefined;
-	if (formInput) {
-		form = JSON.parse(formInput.value);
-		$page.form = form;
-		formInput.remove();
-	}
-	let $props: Record<string, any> = { data };
-
-	// We may have form data in $page.form, either from the hidden input
-	// (above), or added via onformsubmit (below)
-	$props.form = $page.form;
-
-	// Add some special context for submitting Forms client-side
-	const $context = {
-		TorporBuildContext: { onformsubmit: formSubmit },
-	};
-
-	client.layoutStack.push({ path: route.handler.path, data: {}, reuse: false, slotRegion: null });
-	client.layoutStack = newLayoutStack;
-	let layoutStack = client.layoutStack;
-
-	// If there are layouts, work our way upwards, pushing each component into
-	// the default slot of its parent
-	// TODO: There's probably a nicer way to do this with reducers or something
-	let component = clientEndPoint.component as Component;
-	let slots: Record<string, SlotRender> | undefined = undefined;
-	if (handler.layouts) {
-		let slotFunctions: SlotRender[] = [];
-		// The last slot function will render the client component
-		slotFunctions[handler.layouts.length] = function clientComponent(parent, anchor) {
-			let i = layoutStack.length - 1;
-			layoutStack[i].slotRegion = fillLayoutSlot(
-				clientEndPoint.component!,
-				slotFunctions[i + 1],
-				parent,
-				anchor,
-				$props,
-				$context,
-			);
-		};
-
-		// Each earlier slot function will render a layout
-		for (let i = handler.layouts.length - 1; i >= 0; i--) {
-			const layoutEndPoint: PageEndPoint | undefined = (await handler.layouts[i].endPoint())
-				?.default;
-			if (layoutEndPoint?.component) {
-				if (layoutStack[i].reuse) {
-					// Set the parent to add the new content to (from the old
-					// content), clear the range under this point, and set the
-					// component to the slot function within this layout
-					parent = layoutStack[i].slotRegion.startNode.parentNode as HTMLElement;
-					clearLayoutSlot(layoutStack[i].slotRegion);
-					component = slotFunctions[i + 1];
-					break;
-				} else if (i === 0) {
-					component = layoutEndPoint.component as Component;
-					slots = { _: slotFunctions[i + 1] };
-				} else {
-					slotFunctions[i] = function layoutComponent(parent, anchor, _, $context) {
-						layoutStack[i - 1].slotRegion = fillLayoutSlot(
-							layoutEndPoint.component!,
-							slotFunctions[i + 1],
-							parent,
-							anchor,
-							$props,
-							$context,
-						);
-					};
-				}
-			}
-		}
-	}
-
-	if (withHydration) {
-		hydrate(parent, component, $props, slots);
-	} else {
-		try {
-			mount(parent, component, $props, slots);
-		} catch (error) {
-			// TODO: Show a proper Error component
-			parent.innerHTML = '<span style="color: red">Script syntax error</span><p>' + error + "</p>";
-			console.log(error);
-		}
-	}
-
-	// Reset prefetched data on each navigation
-	client.prefetchedData = {};
-
-	return true;
-}

package/src/nav/reload.ts

@@ -1,9 +0,0 @@
-import navigate from "./navigate";
-
-/**
- * Reloads data for the currently loaded page and rerenders it.
- */
-export default async function reload(): Promise<boolean> {
-	const url = new URL(document.location.href);
-	return await navigate(url);
-}

package/src/nav.ts

@@ -1,4 +0,0 @@
-import load from "./nav/load";
-import reload from "./nav/reload";
-
-export { load, reload };

package/src/response/badRequest.ts

@@ -1,19 +0,0 @@
-import response from "./response";
-
-/**
- * 400 Bad Request
- *
- * The HTTP 400 Bad Request client error response status code indicates that the
- * server would not process the request due to something the server considered
- * to be a client error. The reason for a 400 response is typically due to
- * malformed request syntax, invalid request message framing, or deceptive
- * request routing.
- *
- * Clients that receive a 400 response should expect that repeating the request
- * without modification will fail with the same error.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/400
- */
-export default function badRequest(body?: object | string): Response {
-	return response(400, body ?? "Bad request");
-}

package/src/response/created.ts

@@ -1,20 +0,0 @@
-import response from "./response";
-
-/**
- * 201 Created
- *
- * The HTTP 201 Created successful response status code indicates that the HTTP
- * request has led to the creation of a resource. This status code is commonly
- * sent as the result of a POST request.
- *
- * The new resource, or a description and link to the new resource, is created
- * before the response is returned. The newly-created items can be returned in
- * the body of the response message, but must be locatable by the URL of the
- * initiating request or by the URL in the value of the Location header provided
- * with the response.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/201
- */
-export default function created(body?: object | string): Response {
-	return response(201, body);
-}

package/src/response/forbidden.ts

@@ -1,21 +0,0 @@
-import response from "./response";
-
-/**
- * 403 Forbidden
- *
- * The HTTP 403 Forbidden client error response status code indicates that the
- * server understood the request but refused to process it. This status is
- * similar to 401, except that for 403 Forbidden responses, authenticating or
- * re-authenticating makes no difference. The request failure is tied to
- * application logic, such as insufficient permissions to a resource or action.
- *
- * Clients that receive a 403 response should expect that repeating the request
- * without modification will fail with the same error. Server owners may decide
- * to send a 404 response instead of a 403 if acknowledging the existence of a
- * resource to clients with insufficient privileges is not desired.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/403
- */
-export default function forbidden(body?: object | string): Response {
-	return response(403, body ?? "Forbidden");
-}

package/src/response/found.ts

@@ -1,30 +0,0 @@
-import transfer from "./transfer";
-
-/**
- * 302 Found
- *
- * The HTTP 302 Found redirection response status code indicates that the
- * requested resource has been temporarily moved to the URL in the Location
- * header.
- *
- * A browser receiving this status will automatically request the resource at
- * the URL in the Location header, redirecting the user to the new page. Search
- * engines receiving this response will not attribute links to the original URL
- * to the new resource, meaning no SEO value is transferred to the new URL.
- *
- * > Note: In the Fetch Standard, when a user agent receives a 302 in response
- * > to a POST request, it uses the GET method in the subsequent redirection
- * > request, as permitted by the HTTP specification. To avoid user agents
- * > modifying the request, use 307 Temporary Redirect instead, as altering the
- * > method after a 307 response is prohibited.
- *
- * > In cases where you want any request method to be changed to GET, use 303
- * > See Other. This is useful when you want to give a response to a PUT method
- * > that is not the uploaded resource but a confirmation message such as: "you
- * > successfully uploaded XYZ".
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/302
- */
-export default function permRedirect(location: string): Response {
-	return transfer(308, location);
-}

package/src/response/methodNotAllowed.ts

@@ -1,18 +0,0 @@
-import response from "./response";
-
-/**
- * 405 Method Not Allowed
- *
- * The HTTP 405 Method Not Allowed client error response status code indicates
- * that the server knows the request method, but the target resource doesn't
- * support this method. The server must generate an Allow header in a 405
- * response with a list of methods that the target resource currently supports.
- *
- * Improper server-side permissions set on files or directories may cause a 405
- * response when the request would otherwise be expected to succeed.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/405
- */
-export default function methodNotAllowed(body?: object | string): Response {
-	return response(405, body ?? "Method not allowed");
-}

package/src/response/movedPermanently.ts

@@ -1,25 +0,0 @@
-import transfer from "./transfer";
-
-/**
- * 301 Moved Permanently
- *
- * The HTTP 301 Moved Permanently redirection response status code indicates
- * that the requested resource has been permanently moved to the URL in the
- * Location header.
- *
- * A browser receiving this status will automatically request the resource at
- * the URL in the Location header, redirecting the user to the new page. Search
- * engines receiving this response will attribute links to the original URL to
- * the redirected resource, passing the SEO ranking to the new URL.
- *
- * > Note: In the Fetch Standard, when a user agent receives a 301 in response
- * > to a POST request, it uses the GET method in the subsequent redirection
- * > request, as permitted by the HTTP specification. To avoid user agents
- * > modifying the request, use 308 Permanent Redirect instead, as altering the
- * > method after a 308 response is prohibited.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/301
- */
-export default function permRedirect(location: string): Response {
-	return transfer(308, location);
-}

package/src/response/notFound.ts

@@ -1,24 +0,0 @@
-import response from "./response";
-
-/**
- * 404 Not Found
- *
- * The HTTP 404 Not Found client error response status code indicates that the
- * server cannot find the requested resource. Links that lead to a 404 page are
- * often called broken or dead links and can be subject to link rot.
- *
- * A 404 status code only indicates that the resource is missing without
- * indicating if this is temporary or permanent. If a resource is permanently
- * removed, servers should send the 410 Gone status instead.
- *
- * 404 errors on a website can lead to a poor user experience for your visitors,
- * so the number of broken links (internal and external) should be minimized to
- * prevent frustration for readers. Common causes of 404 responses are mistyped
- * URLs or pages that are moved or deleted without redirection. For more
- * information, see the Redirections in HTTP guide.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/404
- */
-export default function notFound(body?: object | string): Response {
-	return response(404, body ?? "Not found");
-}

package/src/response/notModified.ts

@@ -1,34 +0,0 @@
-import transfer from "./transfer";
-
-/**
- * 304 Not Modified
- *
- * The HTTP 304 Not Modified redirection response status code indicates that
- * there is no need to retransmit the requested resources.
- *
- * This response code is sent when the request is a conditional GET or HEAD
- * request with an If-None-Match or an If-Modified-Since header and the
- * condition evaluates to 'false'. It confirms that the resource cached by the
- * client is still valid and that the server would have sent a 200 OK response
- * with the resource if the condition evaluated to 'true'. See HTTP caching for
- * more information.
- *
- * The response must not contain a body and must include the headers that would
- * have been sent in an equivalent 200 response, such as:
- *
- * - Cache-Control
- * - Content-Location
- * - Date
- * - ETag
- * - Expires
- * - Vary
- *
- * > Note: Many developer tools' network panels of browsers create extraneous
- * > requests leading to 304 responses, so that access to the local cache is
- * > visible to developers.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/304
- */
-export default function notModified(location: string): Response {
-	return transfer(304, location);
-}

package/src/response/ok.ts

@@ -1,29 +0,0 @@
-import response from "./response";
-
-/**
- * 200 OK
- *
- * The HTTP 200 OK successful response status code indicates that a request has
- * succeeded. A 200 OK response is cacheable by default.
- *
- * A 200 OK response has a different meaning and format depending on the HTTP
- * request method. Here's how they vary for different methods:
- *
- * - GET: A resource was retrieved by the server and included in the response
- *   body.
- * - POST: An action succeeded; the response has a message body describing the
- *   result.
- * - HEAD: Identical to GET, except there is no message body.
- * - TRACE: The response has a message body containing the request as received
- *   by the server.
- *
- * Although possible, successful PUT or DELETE requests often do not result in a
- * 200 OK response. It is more common to see 201 Created if the resource is
- * uploaded or created for the first time, or 204 No Content upon successful
- * deletion of a resource.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/200
- */
-export default function ok(body?: object | string): Response {
-	return response(200, body);
-}

package/src/response/permanentRedirect.ts

@@ -1,30 +0,0 @@
-import transfer from "./transfer";
-
-/**
- * 308 Permanent Redirect
- *
- * The HTTP 308 Permanent Redirect redirection response status code indicates
- * that the requested resource has been permanently moved to the URL given by
- * the Location header.
- *
- * A browser receiving this status will automatically request the resource at
- * the URL in the Location header, redirecting the user to the new page. Search
- * engines receiving this response will attribute links to the original URL to
- * the redirected resource, passing the SEO ranking to the new URL.
- *
- * The request method and the body will not be modified by the client in the
- * redirected request. A 301 Moved Permanently requires the request method and
- * the body to remain unchanged when redirection is performed, but this is
- * incorrectly handled by older clients to use the GET method instead.
- *
- * > Note: Some Web applications may use the 308 Permanent Redirect in a
- * > non-standard way and for different purposes. For example, Google Drive uses
- * > a 308 Resume Incomplete response to indicate to the client when an
- * > unfinished upload has stalled. See Perform a resumable download on the
- * > Google Drive documentation for more information.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/308
- */
-export default function permanentRedirect(location: string): Response {
-	return transfer(308, location);
-}

package/src/response/response.ts

@@ -1,22 +0,0 @@
-/**
- * Creates a response with the supplied status code and optional body.
- *
- * If the body is an object, it will be converted to JSON and the content-type
- * header set to "application/json". Otherwise, if the body is a string, the
- * content-type header will be set to "text/plain".
- */
-export default function response(status: number, body?: object | string): Response {
-	let headers: Record<string, string> | undefined = undefined;
-	if (body) {
-		if (typeof body === "object") {
-			headers = { "content-type": "application/json" };
-			body = JSON.stringify(body);
-		} else {
-			headers = { "content-type": "text/plain" };
-		}
-	}
-	return new Response(body, {
-		status,
-		headers,
-	});
-}

package/src/response/seeOther.ts

@@ -1,19 +0,0 @@
-import transfer from "./transfer";
-
-/**
- * 303 See Other
- *
- * The HTTP 303 See Other redirection response status code indicates that the
- * browser should redirect to the URL in the Location header instead of
- * rendering the requested resource.
- *
- * This response code is often sent back as a result of PUT or POST methods so
- * the client may retrieve a confirmation, or view a representation of a
- * real-world object (see HTTP range-14). The method to retrieve the redirected
- * resource is always GET.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/303
- */
-export default function seeOther(location: string): Response {
-	return transfer(303, location);
-}

package/src/response/serverError.ts

@@ -1,24 +0,0 @@
-import response from "./response";
-
-/**
- * 500 Server Error
- *
- * The HTTP 500 Internal Server Error server error response status code
- * indicates that the server encountered an unexpected condition that prevented
- * it from fulfilling the request. This error is a generic "catch-all" response
- * to server issues, indicating that the server cannot find a more appropriate
- * 5XX error to respond with.
- *
- * If you're a visitor seeing 500 errors on a web page, these issues require
- * investigation by server owners or administrators. There are many possible
- * causes of 500 errors, including: improper server configuration, out-of-memory
- * (OOM) issues, unhandled exceptions, improper file permissions, or other
- * complex factors. Server administrators may proactively log occurrences of
- * server error responses, like the 500 status code, with details about the
- * initiating requests to improve the stability of a service in the future.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/500
- */
-export default function serverError(body?: object | string): Response {
-	return response(500, body ?? "Server error");
-}

package/src/response/temporaryRedirect.ts

@@ -1,31 +0,0 @@
-import transfer from "./transfer";
-
-/**
- * 307 Temporary Redirect
- *
- * The HTTP 307 Temporary Redirect redirection response status code indicates
- * that the resource requested has been temporarily moved to the URL in the
- * Location header.
- *
- * A browser receiving this status will automatically request the resource at
- * the URL in the Location header, redirecting the user to the new page. Search
- * engines receiving this response will not attribute links to the original URL
- * to the new resource, meaning no SEO value is transferred to the new URL.
- *
- * The method and the body of the original request are reused to perform the
- * redirected request. In the cases where you want the request method to be
- * changed to GET, use 303 See Other instead. This is useful when you want to
- * give an answer to a successful PUT request that is not the uploaded resource,
- * but a status monitor or confirmation message like "You have successfully
- * uploaded XYZ".
- *
- * The difference between 307 and 302 is that 307 guarantees that the client
- * will not change the request method and body when the redirected request is
- * made. With 302, older clients incorrectly changed the method to GET. 307 and
- * 302 responses are identical when the request method is GET.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/307
- */
-export default function temporaryRedirect(location: string): Response {
-	return transfer(307, location);
-}

package/src/response/transfer.ts

@@ -1,14 +0,0 @@
-/**
- * Creates a redirect response with the supplied status code.
- */
-export default function transfer(
-	status: 300 | 301 | 302 | 303 | 304 | 307 | 308,
-	location: string,
-): Response {
-	return new Response(null, {
-		status,
-		headers: {
-			location,
-		},
-	});
-}

package/src/response/unauthorized.ts

@@ -1,21 +0,0 @@
-import response from "./response";
-
-/**
- * 401 Unauthorized
- *
- * The HTTP 401 Unauthorized client error response status code indicates that a
- * request was not successful because it lacks valid authentication credentials
- * for the requested resource. This status code is sent with an HTTP
- * WWW-Authenticate response header that contains information on the
- * authentication scheme the server expects the client to include to make the
- * request successfully.
- *
- * A 401 Unauthorized is similar to the 403 Forbidden response, except that a
- * 403 is returned when a request contains valid credentials, but the client
- * does not have permissions to perform a certain action.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/401
- */
-export default function unauthorized(body?: object | string): Response {
-	return response(401, body ?? "Unauthorized");
-}

package/src/response/unprocessable.ts

@@ -1,18 +0,0 @@
-import response from "./response";
-
-/**
- * 422 Unprocessable Content
- *
- * The HTTP 422 Unprocessable Content client error response status code
- * indicates that the server understood the content type of the request content,
- * and the syntax of the request content was correct, but it was unable to
- * process the contained instructions.
- *
- * Clients that receive a 422 response should expect that repeating the request
- * without modification will fail with the same error.
- *
- * See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/422
- */
-export default function unprocessable(body?: object | string): Response {
-	return response(422, body ?? "Unprocessable");
-}

package/src/response.ts

@@ -1,37 +0,0 @@
-import badRequest from "./response/badRequest";
-import created from "./response/created";
-import forbidden from "./response/forbidden";
-import found from "./response/found";
-import methodNotAllowed from "./response/methodNotAllowed";
-import movedPermanently from "./response/movedPermanently";
-import notFound from "./response/notFound";
-import notModified from "./response/notModified";
-import ok from "./response/ok";
-import permanentRedirect from "./response/permanentRedirect";
-import response from "./response/response";
-import seeOther from "./response/seeOther";
-import serverError from "./response/serverError";
-import temporaryRedirect from "./response/temporaryRedirect";
-import transfer from "./response/transfer";
-import unauthorized from "./response/unauthorized";
-import unprocessable from "./response/unprocessable";
-
-export {
-	response,
-	ok,
-	created,
-	transfer,
-	movedPermanently,
-	found,
-	seeOther,
-	notModified,
-	temporaryRedirect,
-	permanentRedirect,
-	badRequest,
-	unauthorized,
-	forbidden,
-	notFound,
-	methodNotAllowed,
-	unprocessable,
-	serverError,
-};