redbar0n

--- Grok's suggestion (to give an idea of the FC/IS architecture on the backend in JS/TS):

Here's a revised version where the functional core is kept completely pure — no Effect, no Task, no monads of any kind inside the core business logic. We still follow Functional Core / Imperative Shell, but the core now returns plain values + Either-like results (using simple discriminated unions).

Just TS with simple discriminated union style:

// =============================================
// FILE: src/core/types.ts
// =============================================

How to get TypeScript as close as possible to a fully sound static type system?

Like in ReScript, PureScript, OCaml, Elm etc.

To get more sound type inference. To avoid type errors slipping through to production in spite of the type checking.

A sound type system guarantees that if a program passes type checking, it will not produce runtime type errors (no false negatives), ensuring reliability. It is one of the main benefits of using ReScript over TypeScript, which has a superior type system inference (due to it's OCaml roots).

-- Gemini's answer to my queries:

What if you could have vertically sliced MVC-widgets, that looked something like this?

Using React and XState.

//  A vertically sliced "MVC-widget"

//  VIEW:

export default function Users() {

a thread where we can discuss some crazy routing ideas a bit out in the open branching out from the previous discussion on filesystem routes over at: https://discord.com/channels/815937377888632913/1014946079965454366

so, first of all, it seems there is a close alignment between how vite-plugin-ssr and router5 handles routing:

vps: (view === 'overview') @ https://vite-plugin-ssr.com/layouts#nested-layouts
router5 (route === 'dashboard') @ https://youtu.be/hblXdstrAg0?t=197 maybe with the small exception that router5 has the explicit perspective of routes as app state whereas I didn't get the impression from vps that it's viewed as such (even though it technically is still state).

I recommend watching this router5 talk from 2:45 - 7:50 https://youtu.be/hblXdstrAg0?t=165 since it's really key to how I think about view / state separation, and I think of routing as a state separate from the view. (After all, and especially in a client-rendered app, what page it is showing is certainly a major part

	// The following is an example from the language Kitten, but generalizes to other languages.
	// It should be useful for language design and choosing naming conventions for variables and functions.

	// TL;DR: camelCase is most readable/discernable when used in context, as per this simple example extract:

	`n bottles-of-beer on-the-wall` // kebab-case
	`n bottles_of_beer on_the_wall` // snake_case
	`n bottlesOfBeer onTheWall` // camelCase

	// To more fully see the effect yourself, in context, do the following:

	// "Mutable borrows" is where the Rust ownership/borrowing model became too complex for it's own good...


	// A function that mutates a value, but does not return the value. So it only performs an effect, often called a side-effect.
	fn mutate_value(s: &mut String) {
	s.push_str(", world"); // we can mutate the borrowed value. In Rust, push_str returns the unit value, aka. void, so the function does not return the string.
	}

	fn main() {
	let mut hello = String::from("hello");

	;; The following example is:
	"The program that prints the first 25 integers squared."

	;; PS: The example was inspired by this article by C. Martin aka. "Uncle Bob": https://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html

	;; Some necessary background documentation first:
	;;
	;; range - "Returns a lazy seq of nums from start (inclusive) to end
	;; (exclusive), by step, where start defaults to 0, step to 1, and end to
	;; infinity." https://clojuredocs.org/clojure.core/range

	import { useStore } from "../store";
	import ArticlePreview from "./ArticlePreview";

	export default ArticleList = props => {
	const [{ token }, { unmakeFavorite, makeFavorite }] = useStore(),
	handleClickFavorite = (article, e) => {
	e.preventDefault();
	article.favorited ? unmakeFavorite(slug) : makeFavorite(slug);
	},
	handlePage = (v, e) => {

	import { useStore } from "../store";
	import ArticlePreview from "./ArticlePreview";

	export default props => {
	const [{ token }, { unmakeFavorite, makeFavorite }] = useStore(),
	handleClickFavorite = (article, e) => {
	e.preventDefault();
	article.favorited ? unmakeFavorite(slug) : makeFavorite(slug);
	},
	handlePage = (v, e) => {

	// ---
	// The following code is from: https://github.com/dwyl/learn-tdd/blob/master/change.js
	// Note that:
	// - The JsDoc mentioning the params to getChange became out of sync after it apparently was refactored. Therefore, avoid such comments.
	// - There are quite a few comments merely detailing what can be self-evidently / obviously read from the code itself. They don't reveal anything more (like intent/purpose) than the code itself, and just add noise, and can become out of sync, so avoid those.

	var coins = [200, 100, 50, 20, 10, 5, 2, 1];
	/**
	* getChange accepts two parameters (totalPayable and cashPaid) and calculates
	* the change in "coins" that needs to be returned.