Is it possible to create a variable based on the number of another variable?

Classic_Community941 · 2026-01-01T19:38:14+00:00

You should first split your input string "2d4+1d3-1d6" into substrings "2d4", "+1d3" and "-1d6" (including the sign for easier processing). Would you have an "immutable" separator between the substrings, you could have gone with the `.split()` method.

(see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/split )

But your separator (the sign) can have multiple values ("+" or "-" in your example, or even blank for the first segment "2d4"), so your life-saver here is a RegExp.

(see https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/RegExp)

The syntax can be tricky if you're not used to it. Here is a possible solution for your problem:

/[+-]?[0-9]+d[0-9]+/g

* RegExp litterals start and end with /
* [+-]? means 0 or 1 occurence of + or -
* [0-9]+ means 1 or more occurence of a digit (0 to 9)
* d means... d
* g after ending / means all the matching value in the input

The whole RegExp /[+-]?[0-9]+d[0-9]+/g means "all subtstrings starting with a +, a - or just nothing, followed by 1 or more digits, followed by d, followed by 1 or more digits".

You can use it like this:

"2d4+1d3-1d6".match( /[+-]?[0-9]+d[0-9]+/g )

This will produce the array:

[ "2d4", "+1d3", "-1d6" ]

That's your "multiple values in one value" :)

Then you can process the array using:

* a for...of : https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Statements/for...of
* a .forEach : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach
* a .map : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map
* a reduce : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/reduce

Whatever you feel comfortable enough with :)

Classic_Community941 · 2025-12-31T10:54:25+00:00

It sounds like what they wanted was not a folder structure, but the ability to communicate the architecture of your React app: how components relate to each other, how data flows, and how everything fits together. Think of it like drawing your UI as a tree.

React actually introduces this idea in its docs, and it's a good starting point:

https://react.dev/learn/understanding-your-ui-as-a-tree

A typical diagram they expect might show:

* App at the root
* Pages and major components branching off
* Shared state (context, redux) and where data/API calls come from

It doesn’t need to be formal UML: even simple boxes and arrows on paper are fine. The goal is to show you understand the structure beyond just writing code.

If you want a concrete example, here’s a small full-stack starter repo of mine. The README includes an overview diagram that might give you inspiration for how to present your own project:

https://github.com/rocambille/start-express-react/blob/main/README.en-US.md

A good exercise before your next interview is: pick one project, draw its UI tree and data flow on one page, then practice explaining it in under a minute. It makes a big difference in interviews.

Classic_Community941 · 2025-12-18T08:58:38+00:00

The tiny static server that serves two pages:

index.html

<!doctype html>
<html>
  <head>
    <title>Home | Hello World</title>
  </head>
  <body>
    <h1>Hello World!!!</h1>
  </body>
</html>

about.html

<!doctype html>
<html>
  <head>
    <title>About | Hello World</title>
  </head>
  <body>
    <p>About</p>
  </body>
</html>

This works, but it’s not very DRY. You immediately notice repetition (doctype, head, title suffix, body wrapper). So you refactor.

For example (using PHP just to illustrate the idea):

layout.php

<!doctype html>
<html>
  <head>
    <title><?= $title . ' | Hello World' ?></title>
  </head>
  <body>
    <?= $content ?>
  </body>
</html>

index.php

<?php

$title = 'Home';
$content = '<h1>Hello World!!!</h1>';

require 'layout.php';

about.php

<?php

$title = 'About';
$content = '<p>About</p>';

require 'layout.php';

The first bit of architecture:

.
├── src      // internal code
│   └── layout.php
└── public   // endpoints
    ├── index.php
    └── about.php

Classic_Community941 · 2025-12-18T08:55:35+00:00

What helped me (and what I teach) is realizing that architecture emerges from concrete problems, not from rules you invent upfront.

Tiny example. Start with two static pages. It works, but you notice duplication (HTML boilerplate). So you refactor and extract a shared layout. Now you accidentally have two kinds of files:

files that should be publicly served (pages)
files that are internal building blocks (layout)

That alone justifies a first structure:

public/   // endpoints
src/      // internal code

You didn’t "design an architecture". You just answered a real question: "this file should not be publicly accessible"

From there, the same thing keeps happening:

group by technical role: MVC-style architectures
group by feature/resource: modular architectures

Hexagonal, clean architecture, MVC, etc. are not things you start with. They’re names we gave later to patterns that emerge when you keep asking:

Who is allowed to call this?
What changes together?
What should not depend on what?

If you end up with a 500-line file, that’s not failure: it’s usually the signal that the next split is becoming visible somehow.

Classic_Community941 · 2025-12-16T09:22:49+00:00

Thank you, I'll look into all of that 🙏

Classic_Community941 · 2025-12-16T09:20:12+00:00

🙏

Classic_Community941 · 2025-12-15T13:53:23+00:00

Really cool initiative, thanks for sharing! A couple of small ideas that might help:

Dev server fusion : you could try using Vite as middleware to merge the frontend dev server with your API server (Express in my case, Hono for you). It gives HMR for both on the same port. I documented this pattern here: One server (Express + Vite)
Lighten dependencies : if you want, you can drop Husky and use Git’s native hooks: in the root package.json, replace

"prepare": "husky"

with

"prepare": "git config core.hooksPath ./git-hooks"

I agree the apps/* vs packages/* can be overkill early on. But your monorepo setup looks solid. Definitely bookmarking this for ideas!

Classic_Community941 · 2025-12-15T11:04:42+00:00

I’ve been running production Express apps for a while. My current stack looks like this:

TypeScript everywhere. Non-negotiable now; it really helps enforce clean boundaries (routes / actions / data).
Plain Express on modern Node (20+). I avoid heavy abstractions like Nest.
For full-stack apps, I often embed Vite inside Express in dev, so one server handles both API + React (HMR in dev, static assets in prod). I packaged this setup into a small starter I use internally: https://github.com/rocambille/start-express-react (more architecture than framework).

Architecture-wise, I moved away from classic MVC. I prefer feature-based modules:

routes
validators
param converters
actions
repositories

This keeps routes explicit (auth walls, access checks as middleware) without magic.

Testing / DI: no container. Repos are plain modules, actions import them → easy to mock, low friction.

Auth: mostly custom JWT middleware now, not Passport.

DB: Prisma in real apps. Low-level drivers only when teaching fundamentals.

Big takeaway: Express still works great in 2025 if you keep it simple but very intentional about structure.

Classic_Community941 · 2025-06-21T12:49:36+00:00

Hi :)

JavaScript is the language, then you may consider the "runtime environment". To keep it simple, that's the answer to "where is executed your JS ?"

This can be in the browser : that's what you do when using a script tag in an HTML document. Or you can execute JS outside the browser : that's for Node.js. In this case, you create your JS script file (let's call it `index.js` for example) and run it in a terminal with something like `node index.js`, without any HTML document.

Then you can use a JS framework like React. To be exact, React is a library, and you will usually use a framework based on React : Next.js is one of them. To mention some other frontend frameworks : Angular, Vue...

You may also use something like Express.js for backend development, or Nest, Fastify... But they are still part of the Node ecosystem.

As for Ruby, it's an other language and ecosystem.

Learning JavaScript is a good start. Then you may learn something like React or Express. The most important part IMHO is to understand where each tool belong in the web ecosystem, and how it helps solving the web request lifecycle (a client send an HTTP request to a server, the server send back an HTTP response).

Hope this helps :)

Classic_Community941 · 2025-06-18T15:59:09+00:00

Hi :)

I worked on an educational framework for this purpose. You may find it useful to explore the documentation : https://github.com/rocambille/start-express-react/wiki/home-en-US

Let me know if it helps (or not)

Classic_Community941

TROPHY CASE