redbar0n

Here's an idea:

A front-end architecture for React apps with simple decentralized stores and explicit rendering control.

As an experiment (worked out together with Gemini AI), this should be a practical and very performant realization of the Functional Core, Imperative Shell (FCIS) architecture for a TypeScript front-end in React:

• We avoid using most React hooks (aka. side-effects), such as useState, useReducer, useContext, useMemo / useCallback, and useEffect.

• We let React be strictly and only responsible for the View layer (the Functional Core), and for the Imperative Shell we use decoupled Stores (aka. ModelControllers: state + logic) colocated alongside the view Components. Our API becomes a simple useStore (to wire it up, so we can use React's component tree for structure, and don't have to replicate it in the Imperative Shell), and a general `triggerAction(action, payload)

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
// =============================================

redbar0n

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:

redbar0n

// 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:

redbar0n

// "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");

redbar0n

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() {

redbar0n

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

redbar0n

;; 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

redbar0n

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) => {

redbar0n

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) => {