zlatko

Not that simple. You have several moving parts just in your frontend. But all of your frontend is still accessible. E.g. if you run ng build, the output javascript will contain links to your module:

/ src/app/app.routes.ts
var routes = [
  {
    path: "no-match",
    canMatch: [noMatchGuard],
    loadChildren: () => import("./chunk-2W7YI353.js").then((m) => m.NoMatchComponent)
  },
  {
    path: "no-activate",
    canActivate: [noActivateGuard],
    loadChildren: () => import("./chunk-JICQNUJU.js").then((m) => m.NoActivateComponent)
  }
];

So whoever wanted to see what's in those separate files and just load the code in those components directly.

And of course, you have the backend completely separately anyway. Those two lazy-loaded modules - whether protected by guards or not - will contain links to your /count. If they're called or not is not relevant, whoever is interested can read the code and find the URLs. Someone can just call your /count without even looking at your code.

See if this lil image of the moving parts helps:

shaking my (trademark) head?

Hey all, I just spotted the question by accident. I'll try to answer it in case you're still wondering, or for some future concern.

The difference is that canMatch is being evaluated first, runs before you even look into the URL. Imagine that canMatch guard is only allowing admins in.

That means you can e.g. prevent even attempting to load the routes (e.g. lazily) if you know your current user is an admin. They try to open /site-settings or /users page or similar - and you just nope them back.

CanActivate, in contrast, will first go load the remote route, then try to match the user.

Now, you also asked why. Well, the difference is usually tiny, but it might make sense. Let's say you have some data loading, some actions being performed, some background sync operations running when you load a lazy route /admin. Example, you have /admin page, but when you load it, canActivate router needs to go back to server and ask if this particular admin can administer this particular tenant. If you use canActivate, some of these are running always. And if you know your user is not an admin at all, you don't even try to load the module, and you save that time.

Tiny bit of difference, but it can help sometime.

So, send'em a dicpic and you're in :)

considering where the garbage came from, maybe we should stop shitposting :)

(sorry for the late response, I have to get in the habit of checking my Lemmy account)

No, I get that - a stylesheet denotes a class by having a dot. A JavaScript API for adding a CSS class omits this redundancy.

I was saying that the author might not be wrong to want to avoid the redundancy in rust example as well (since it explicitly mentions CSS classes).

I mean, it is not embarrassing for you. In the browser, the CSS's "native platform", you add classes, via the JavaScript API, without the dot. It's not a stupid assumption.

To have to add the dot in the CSS class name seems a bit of an oversight in the gtkrs API.

Actual programmer

I wonder if JJ anonymous branches would be something that solves this. I've only read about it, have not used JJ yet.

Or meet old ideological dogs like me :P

Much better integrated refactoring support. Much better source code integration support. Much better integrated debugging support. Much better integrated assistive (but not ai) support.

Vscode can do many things IntelliJ can, but not all, and many of them require fiddling with plugins.

Usually, JB is also faster (if your dev machine can run it, but in my experience most devs have beefy machines).

Zed is also lightspeed fast compared to either vscode or JetBrains' stuff.