Відео

you can see my neotree config here: github.com/joshuamorony/lazyvim/blob/main/lua/plugins/neo-tree.lua (note the window position = "right" config specifically)

I think the idea about a lot of our mindset being implicit is interesting. I feel like I can even use an idea or pattern quite effectively for a long time before some final piece clicks into place that allows me to think about it in a more concrete way (and a way that I could explain without vaguery and hand waving). Declarative code was very much like this for me - for a long time I used the concepts and benefited from them, but then at some point it's like some final little piece of the puzzle clicks in that reveals everything with much more clarity. I often get the sense that my subconscious mind knows these things better than I do (which leads to those ah-ha! moments in the shower), the trick I feel is getting to the point where I can think about it clearly in my conscious mind. Feels a bit woo-woo but I've wondered if there are ways to better or more intentionally leverage our subconscious mind or if there has been much research done in that area.

Definitely not woo woo . I've read a few psychology books and I think most people underestimate how much of who they are and what they think is subconscious.

​@@mfpears have you read The Master and His Emissary? It's been on my reading list for years now, if I remember correctly it covers the idea of our conscious mind sort of being like a dumb king that thinks it's in control/thinking of all these great plans, but most of it is coming from our subconscious mind (think it touches on implications of the split brain experiments). Curious to know if you think it's worthwhile if you have read it.

It's funny because this is quite literally a dependency inversion, but I've never really though about DI from SOLID in that way (maybe I should), but I think about it more in the context of depending on abstractions instead of concretions (not changing the direction of a dependency)

🙃

Because its supposed to be a specific union type or strings (e.g. "a" | "b" | "c"), without "as const" the type will just be a generic "string" not a specific string

@@JoshuaMorony that makes sense, thank you. I was creating specific types but I like your const approach most. Thank you Josh, been trying the signalslice and I find it awesome :)

And to not unnecessarily fetch data multiple times I have implemented a caching service using cashew using cache buckets and a cache bucket gets cleared by my backend when someone changes something -> a cache clearing event with the specific bucket name is sent to all clients connected via SignalR. Don't know how well that will scale though but it works very well and I have made it so that if you fetch lets say all products it also caches the keys of each entity and if you fetch a single product it won't have to go to the server if said product has already been fetched with the "get all" request (or paginated request in my case)

@@MrBloodWoork Wow, neat idea. I used to cache manually some standalone bits of state that were fetched often, but never implemented scaleable solution. I m just wondering. How exactly backend clears cached data? You receive some kind of array key with changed objects or something?

@@loko1944 No, in the frontend I have so called cache buckets. With cashew you can decide for every request which cache bucket the data should be stored in. I used a string backed enum to assign the names to the buckets. Let's assume we have the products cache bucket and we use it for the GET /products request in the frontend. Now in my backend I just call my cache invalidation service with the products enum value right after code that changes or deletes a product. So when POST /products is called then a message is broadcasted to all connected clients to clear their cache with the cache bucket name "products". However I did have to create a dependency map and clear all other buckets which depend on products because e.g. an asset has a product and so assets have to be cleared too because I have joined assets and products when fetching assets to be able to display the assets product name.

@loko1944 No, in the frontend I have so called cache buckets. With cashew you can decide for every request which cache bucket the data should be stored in. I used a string backed enum to assign the names to the buckets. Let's assume we have the products cache bucket and use it for the GET /products request in the frontend. Now in the backend I just call my cache invalidation service with the products enum value right after code that changes or deletes a product. So when POST /products is called then a message is broadcasted to all connected clients to clear their cache with the cache bucket name "products".

@@loko1944 However I did have to create a dependency map because e.g. an asset has a product and so assets have to be cleared too because I have joined assets and products when fetching assets so I can display their product names.

I'm sure I'll be reading more from Charlie, I picked the book up on a whim but I don't think I've taken so many notes from a book in my life

If I'm following you correctly then I think that makes sense for having more granular control over what is exposed (I haven't personally done something like it though)

Yes this is mostly what is recommended and i think Manfred Styer and the angular architect team started it. Inverting is good but it ends up ugly as time pass cause you end up having a shared service that has trivial APIs cause of some small dependency.

@@g-luu Interesting to know. I never did large projects that way thats why i probably never notice that

I've decided always invert is terrible advice now

@@JoshuaMorony thinking in takeUntilDestroyed() terms no one should unsubscribe as long as your chanel is available 😅

I don't know your situation, nor do I really know the current job market first hand as I have not had to deal with it any time recently, but my guess is that it sounds like you already would "qualify" for an entry level role (maybe beyond that), and maybe the issue lies somewhere other than needing to know more stuff to land a role (likely a big part of the problem is that from what I have heard the market for entry level positions is very competitive/difficult at the moment). This isn't particularly useful advice, because I don't think I have good advice to give on how to land a job in today's market, but I did want to make it clear that I don't think going through my course is necessarily going to help you land a job. That said, at least from my perspective, someone who has a strong grasp of all the topics covered in the course would be among the best Angular developers (but also, that would come through repeated application of these concepts over a period of time to develop that "strong grasp"). But ultimately, even if you have all these skills, it still might be difficult to land a job without prior positions/network.

I don't have a video, and my tmux config isn't public, but my neovim config is available here: github.com/joshuamorony/lazyvim/

100% agree. I shared the same opinion back when signals were introduced. They don't solve anything that rxjs doesn't already solve (except maybe for "glitches" but those can be worked around in rxjs) but now you have a fractured ecosystem where every Angular app becomes a mess of mutation with zonejs + signals + rxjs. Unfortunately the Angular team will keep adding changes to the point where it will become a mix of React/Vue/Svelte instead of having its own identity.

I got into some thoughts around this in this video: ua-cam.com/video/iA6iyoantuo/v-deo.html but my general opinion is that signals are a better way to represent state, and observables are a better way to handle events, and the flow I've landed on in my apps of starting with observables which flow through to signals to be consumed by the components I quite like/am happy with. But if you do go the pure RxJS approach I don't think there's anything wrong with that (generally speaking, a pure RxJS approach is going to be fine, a pure signals approach might be questionable)

@@JoshuaMorony thanks man

@@valcron-1000 Signals may become an integral part of Javascript, FYI, so there's not running away from it. It looks like they're here to stay.

Ah yes this is a good point I'll add this, but for v18 the only entirely new lesson is this one which covers signal APIs that were not present previously: angularstart.com/modules/basic-angular-concepts/7 The rest of the updates have mostly been updating all the code to make use of the new signal based APIs where they were previously using the old APIs (e.g. @Input, @ViewChild etc)

Coupon doesn't apply

@@biovawan there isn't any coupon code required, the price is just reduced by default during the sale

This video was published just after v17 and I think before I started getting more seriously involved in Analog - personally today I'd use Analog, but I still think it's useful to cover what Angular can do alone

@@JoshuaMorony I agree completely :) I was only surprised because I think you mentioned Svelte-kit which is also nice... but not as nice :) but true that was 6m ago, time flies

The way I see it, these changes are what the Angular team think are necessary to make Angular congruent with where frontend/the web is heading, and it is heading in a direction that requires a shift. But Angular is also committed to not pulling the rug out from under people (which you could argue happened with Angular 2), and so we get this slow/somewhat awkward course correction that hopefully finds a nice balance between evolving but also maintaining stability. The changes feel like the right move to me, but you could also argue that the Angular team have the direction wrong and that things like signals and zoneless aren't needed, or that Angular should just focus on keeping what we already have stable rather than evolving - but, as I hint at in the video, I see that as a path toward Angular becoming a "legacy" framework which is something I personally wouldn't want to see happen. So to address your question more directly, it makes Angular "modern" because it's what the Angular team thinks is required to make it modern - you could debate whether they are right about that or not though.

@@JoshuaMorony It would be interesting if in the future after this change, "modern" is decided to be (or more capable of being) automatic no overhead optimistic change detection triggers and it all comes back around

It's always going to be the case that a tool/framework/whatever is going to have to "adapt or die" especially in the web space - it's just not going to be the case, especially for something that Google is heavily relying on for their own apps, that something is going to go on existing in the frontend space for 20 years and not make changes/course corrections. Certainly you can have the view that Angular is moving/evolving in the wrong direction, but to expect things not to change/not need to update things over time is not realistic imo

@CesarLP96We moved from one of our projects. It has some DX improvements due to no Zone js patching but the performance was already fine so can't really notice any changes.