No products found!
} ``` Explanation: * `@if` decides whether the block of HTML should exist in the DOM at all. * If `products.length > 0`, Angular adds the ``. Legacy note (older Angular): ```html
No products found!
``` `*ngIf` is still supported, but the new `@if` syntax is the recommended style going forward. --- ## Looping over data with @for Let’s populate some mock products: ```ts // product-list.ts export class ProductList { products: Product[] = [ { id: 1, title: 'Keyboard' }, { id: 2, title: 'Microphone' }, { id: 3, title: 'Web camera' }, { id: 4, title: 'Tablet' } ]; } ``` Now, use `@for` in the template: ```htmlNo products found!
}No products found!
}No products found!
}You selected: {{ selectedProduct.title }}
} ``` Explanation: * `(click)="selectedProduct = product"` listens for the browser’s `click` event and executes the assignment in the component instance. * `selectedProduct` becomes the currently clicked product, and the `@if` block below reacts by showing its title. --- # Styling Components and View Encapsulation Angular lets you bind classes and styles dynamically. ## Class binding ```html{{ selectedProduct ? 'Product chosen' : 'No product selected' }}
``` Explanation: * `[style.color]` controls a single style property dynamically, based on component state. ## View encapsulation By default, Angular scopes CSS per component (Emulated mode), so styles from `product-list.css` will only affect that component’s template. ```ts import { Component, ViewEncapsulation } from '@angular/core'; @Component({ selector: 'app-product-detail', templateUrl: './product-detail.html', styleUrl: './product-detail.css', standalone: true, encapsulation: ViewEncapsulation.Emulated // default }) export class ProductDetail { } ``` If you explicitly set: ```ts encapsulation: ViewEncapsulation.None ``` then styles defined in `product-detail.css` can leak into other parts of the app. This can be useful for global styling, but must be used carefully. --- # Passing Data Between Components (Inputs and Outputs) Real-world applications rarely keep all UI in a single component. Often, a parent component owns the data and passes a piece of it down to a child component. ## Passing data down with input() Create a detail component: ```ts // src/app/product-detail/product-detail.ts import { Component, input } from '@angular/core'; import type { Product } from '../product-list/product-list'; @Component({ selector: 'app-product-detail', templateUrl: './product-detail.html', styleUrl: './product-detail.css', standalone: true }) export class ProductDetail { product = inputYou selected: {{ product()!.title }}
} ``` Explanation: * `product = inputNo products found!
}You selected: {{ product()!.title }}
Detail says: {{ detail.product()!.title }}
``` Explanation: * `#detail` creates a template reference to the `ProductDetail` instance. * This reference exposes the public API of `ProductDetail` (here: `product()`). ## Querying a child in TypeScript with viewChild You can also get the child instance from the parent class: ```ts // product-list.ts import { Component, AfterViewInit, viewChild } from '@angular/core'; import { ProductDetail } from '../product-detail/product-detail'; @Component({ selector: 'app-product-list', templateUrl: './product-list.html', styleUrl: './product-list.css', standalone: true, imports: [ProductDetail] }) export class ProductList implements AfterViewInit { productDetail = viewChild(ProductDetail); ngAfterViewInit(): void { console.log('Detail product:', this.productDetail()?.product()); } } ``` Explanation: * `viewChild(ProductDetail)` tells Angular to look for a `ProductDetail` in this component’s view. * `ngAfterViewInit` is the hook where the child is guaranteed to be created and accessible. Legacy note: Previously: ```ts @ViewChild(ProductDetail) productDetail!: ProductDetail; ``` --- # Change Detection Strategy Angular automatically refreshes views when data changes. By default, it runs change detection for the entire component tree on each relevant event. You can optimize this with `ChangeDetectionStrategy.OnPush`: ```ts import { Component, ChangeDetectionStrategy } from '@angular/core'; @Component({ selector: 'app-product-detail', templateUrl: './product-detail.html', styleUrl: './product-detail.css', standalone: true, changeDetection: ChangeDetectionStrategy.OnPush }) export class ProductDetail { // ... } ``` Explanation: * With `OnPush`, Angular will only re-check this component when: * An input reference changes * An event handler on this component runs * An observable bound in the template emits (via async pipe), etc. * This significantly improves performance in large and complex UIs. --- # Lifecycle Hooks Overview Lifecycle hooks allow you to run custom logic at specific moments in a component’s life. Common hooks: * `ngOnInit` – runs after the component’s inputs are first set. * `ngOnDestroy` – runs right before Angular removes the component from the DOM. * `ngOnChanges` – runs whenever an input binding changes. * `ngAfterViewInit` – runs after the view and child views have been initialized. Example: ```ts import { Component, OnInit, OnDestroy, OnChanges, SimpleChanges, AfterViewInit } from '@angular/core'; @Component({ selector: 'app-product-detail', templateUrl: './product-detail.html', styleUrl: './product-detail.css', standalone: true }) export class ProductDetail implements OnInit, OnDestroy, OnChanges, AfterViewInit { ngOnInit(): void { // Good place to fetch data or initialize values console.log('ProductDetail initialized'); } ngOnChanges(changes: SimpleChanges): void { // React to input changes console.log('Changes:', changes); } ngAfterViewInit(): void { // Child components and view are ready console.log('View initialized'); } ngOnDestroy(): void { // Cleanup: timers, subscriptions, listeners, etc. console.log('ProductDetail destroyed'); } } ``` Explanation: * Each hook gives you a predictable place to put specific kinds of logic: * `ngOnInit` instead of doing heavy work in the constructor. * `ngOnDestroy` to release resources. * `ngOnChanges` to react to new input values. * `ngAfterViewInit` to work with child components or DOM elements that weren’t available earlier. --- # Summary In this chapter you have seen how, in **Angular 20**: * Components are generated with **simpler file names** like `product-list.ts`, `product-list.html`, `product-list.css`. * Standalone components (`standalone: true`) and explicit `imports` have become the default way to structure an app. * The modern control-flow syntax (`@if`, `@for`, `@switch`) replaces older structural directives in new code, while you still need to understand `*ngIf`, `*ngFor` and `ngSwitch` for legacy templates. * Data flows into components via `input()` and out via `output()`, replacing `@Input` and `@Output` in new code. * Class and style bindings, along with view encapsulation, give you fine control over component-level CSS. * Template reference variables and `viewChild` let you reach deeper into the component tree when necessary. * Change detection strategies and lifecycle hooks help you tune both performance and behavior. [1]: https://blog.ninja-squad.com/2025/05/28/what-is-new-angular-20.0?utm_source=chatgpt.com "What's new in Angular 20.0? - The Ninja Squad blog" # Git # Git-Grundlagen: Fork vs. Branch Um die Versionsverwaltung effizient zu nutzen, ist es wichtig, den Unterschied zwischen einem **Branch** (Zweig) und einem **Fork** (Abspaltung) zu verstehen. Beide dienen der Isolation von Code-Änderungen, setzen aber auf unterschiedlichen Ebenen an. ## 1. Der Branch (Der Zweig) Ein Branch ist ein Zeiger auf einen bestimmten Entwicklungsstand innerhalb eines **einzelnen Repositorys**. Er ist die kleinste Einheit, um Änderungen getrennt vom Hauptcode (meist `main` oder `master`) zu entwickeln. * **Ebene:** Repository-intern. * **Lebenszyklus:** Ein Branch ist oft kurzlebig. Er wird für ein Feature oder einen Bugfix erstellt und nach Abschluss der Arbeit per *Merge* oder *Rebase* wieder in den Hauptstamm integriert. * **Berechtigung:** Man benötigt Schreibrechte für das Repository, um einen Branch zu pushen. * **Praxis-Beispiel:** Wenn ich in meinem Dashboard-Projekt eine neue Funktion teste, erstelle ich dafür einen Branch, um den stabilen Code nicht zu gefährden. ## 2. Der Fork (Die Abspaltung) Ein Fork ist eine **vollständige Kopie** eines gesamten Repositorys unter einem neuen Besitzer-Account. Technisch gesehen ist es ein neues, eigenständiges Repository, das jedoch die Verbindung zum Original (dem „Upstream“) beibehält. * **Ebene:** Account- / Server-Ebene. * **Lebenszyklus:** Ein Fork ist oft langlebiger. Er wird genutzt, um unabhängig am gesamten Projekt zu arbeiten, ohne das Original zu beeinflussen. * **Berechtigung:** Jeder kann einen Fork von einem öffentlichen Projekt erstellen, ohne Schreibrechte am Original zu besitzen. * **Praxis-Beispiel:** Bei komplexen Experimenten (z. B. wenn K.I.-Agenten großflächig Code umbauen) nutze ich einen Fork. So kann ich das gesamte Projekt spiegeln und experimentieren, ohne mein Haupt-Repo mit unzähligen Test-Branches zu fluten. ## 3. Direkter Vergleich | Merkmal | Branch | Fork | | --- | --- | --- | | **Speicherort** | Im selben Repository | In einem neuen, eigenen Repository | | **Abhängigkeit** | Fest mit dem Hauptprojekt verbunden | Eigenständig (mit Link zum Original) | | **Zusammenführung** | `git merge` oder `git rebase` | Pull Request (PR) an das Original | | **Sichtbarkeit** | Für alle Projektbeteiligten sichtbar | In meinem eigenen Account-Bereich | ## 4. Kombination im Workflow In der Praxis werden beide Konzepte oft kombiniert. Ein typischer Workflow sieht so aus: 1. Man erstellt einen **Fork** eines Projekts, um eine eigene Arbeitsumgebung zu haben. 2. Innerhalb dieses Forks arbeitet man mit verschiedenen **Branches**, um einzelne Features sauber zu trennen. 3. Ist ein Feature fertig, wird es im Fork gemerged und bei Bedarf per Pull Request dem Original-Projekt zur Verfügung gestellt. # Golang # Basic Installation of Go and Writing Your First Program Before diving into complex projects, you need to set up your local environment so you can run, build, and compile Go code. Once the environment is ready, we will write a simple "Hello World" application to test it out. ## Part 1: Installing the Go Runtime To build and execute Go programs, you must install the Go Runtime. 1. Open your browser and navigate to `golang.org/dl`. 2. Find the download link for your operating system (macOS, Windows, or Linux) and grab the installer. 3. Run the installer and click through the standard installation prompts. 4. **Verify the installation:** Open your computer's terminal and type the single word `go`, then hit enter. You should see a long help message appear on the screen. This `go` command is the primary tool you will use to interact with the Go language. ## Part 2: Configuring the Editor (VSCode) While you can use any editor (like Atom or Sublime Text), **Visual Studio Code (VSCode)** is highly recommended because it offers some of the best built-in integration with Go. 1. Download VSCode from `code.visualstudio.com` and install it. 2. Open VSCode, navigate to the top menu bar, click on **View**, and select **Extensions**. 3. Search for "Go" and install the extension named **"Rich Go language support for Visual Studio"**. 4. **Important Step:** To ensure the extension can successfully install its underlying command-line tools, you must completely quit and restart the VSCode editor. 5. Open a new file and change the language mode in the bottom right corner to **Go**. A yellow prompt will appear saying **"Analysis Tools Missing"**—click **Install** to allow a terminal window to grab the final tools needed to analyze your code. --- ## Part 3: Writing Your First Program Now that the environment is ready, let's write a tiny application. 1. Create a new folder on your computer called `Hello World` and open this folder in your code editor. 2. Inside this directory, create a new file named `main.go`. 3. Add the following code exactly as it appears. Ensure you use double quotes (not single quotes) around your strings: ```go package main import "fmt" func main() { fmt.Println("Hi there") } ``` ## Part 4: How to Run the Code To run your project, open your terminal and navigate inside your `Hello World` directory. You can use the Go Command-Line Interface (CLI) to execute the code in two different ways: * **`go run main.go`**: This command takes your file, compiles it, and immediately executes the result. When you run this, you will instantly see `Hi there` printed on the screen. * **`go build main.go`**: This command will *only* compile your program; it does not execute it automatically. Running this will spit out a runnable executable file named `main` (or `main.exe` on Windows) directly into your folder. You can then execute that file manually. ## Part 5: Breaking Down the Code Even though this is a simple file, it reveals the fundamental structure of all Go programs. * **`package main`**: A package is a collection of common source code files. The name `main` is sacred in Go; it specifically tells the compiler that you are making an *executable* package that will spit out a runnable file, rather than a reusable dependency library. Any time you make an executable package, it must contain a function called `main`. * **`import "fmt"`**: By default, your package is isolated. The `import` statement gives your package access to functionality written in another package. `fmt` (short for "format") is a part of Go's Standard Library, and it is primarily used to print information out to the terminal. * **`func main()`**: `func` is short for function. We declare a function by providing the keyword `func`, the function's name, a set of parentheses for arguments, and curly braces containing the body of our logic. # Understanding Go Slices: The Mechanics of Reference Types In Go, passing a **struct** to a function typically results in an independent copy. If you modify that struct inside the function, the original remains untouched. However, slices exhibit a surprising behavior: modifying a slice inside a function updates the original caller's data. This often leads developers to believe Go has special rules for slices, but the behavior is actually a logical result of how Go manages memory and data structures. ### The Anatomy: Slices vs. Arrays To understand this, we must first distinguish between an array and a slice. In Go, an **array** is a primitive, fixed-length data structure. Because arrays cannot grow or shrink, they are rarely used directly. Instead, we use **slices**, which are essentially a sophisticated "header" that sits on top of an array. When you declare a slice, Go internally creates two separate entities in memory. The first is the **slice header**, a small data structure containing three specific fields: a **pointer** to the underlying data, the current **length** of the slice, and its total **capacity**. The second entity is the **underlying array**, which contains the actual elements and exists at a separate memory address. ### The "Pass-by-Value" Crux Go is strictly a "pass-by-value" language. When you pass a slice into a function, Go does exactly what it does with a struct: it makes a copy of the value. However, the value being copied is the **slice header**, not the underlying array. This is the "gotcha" of Go development. Even though the function receives a brand-new copy of the header, that copy contains the exact same memory address in its pointer field. Therefore, both the original slice header and the function's copy are pointing to the same underlying array. When you modify an element inside the function, you are reaching through the pointer to the "true" source of data in memory. This is why slices are categorized as **reference types**, alongside maps, channels, and pointers. ### Contrast with Value Types In contrast, **value types**—which include integers, floats, booleans, strings, and structs—behave differently. For these types, the "value" is the data itself. When you pass a struct, the entire set of fields is copied to a new memory location. Without using an explicit pointer (using the `*` and `&` operators), a function is only ever working on a local, temporary version of that data. ### Code Example: Slices vs. Structs The following code demonstrates how Go treats a value type (struct) versus a reference type (slice) when passed to a function. ```go package main import "fmt" type Person struct { Name string } func main() { // 1. Value Type Behavior (Struct) myPerson := Person{Name: "Alice"} updateStruct(myPerson) fmt.Println("Original Struct:", myPerson.Name) // Output: Alice (Unchanged) // 2. Reference Type Behavior (Slice) mySlice := []string{"Apple", "Banana"} updateSlice(mySlice) fmt.Println("Original Slice:", mySlice[0]) // Output: Orange (Changed!) } func updateStruct(p Person) { p.Name = "Bob" } func updateSlice(s []string) { s[0] = "Orange" } ``` In the example above, `updateStruct` receives a full copy of the `Person` object, so the original `myPerson` remains "Alice." However, `updateSlice` receives a copy of the slice header. Since that header points to the same underlying array as `mySlice`, changing the first element to "Orange" updates the data that both headers reference. # The Append Behavior: Length, Capacity, and the "Resizing" Trap While passing a slice to a function allows you to modify existing elements, using the `append` function inside that same function introduces a common pitfall. To understand why, we have to revisit the **Slice Header**—the small data structure containing the pointer, length, and capacity. ### The Mechanism of Append When you call `append` on a slice, Go performs a specific set of operations: 1. It checks if the **capacity** of the underlying array is large enough to hold the new elements. 2. If there is room, it adds the elements to the array and increments the **length**. 3. If there is **not** enough room, Go allocates a brand-new, larger array, copies the old elements over, and updates the **pointer** to this new memory location. ### Why Changes to Length/Capacity Don't "Stick" Because Go is **pass-by-value**, the function receives a copy of the slice header. While this copy points to the same underlying array, the `length` and `capacity` fields are local variables within the function's scope. * **Scenario A (Within Capacity):** If you append an item and the array has space, the function updates the shared underlying array. However, it only updates the **local copy** of the `length` field. When the function returns, the caller’s slice header still has the old `length`, so it "doesn't see" the new element, even though it exists in the array. * **Scenario B (Exceeding Capacity):** If the append forces a reallocation, the function creates a new array. The local slice header's **pointer** is updated to this new address. The original slice header in the calling function still points to the **old array**. At this point, the two slices are completely disconnected. ### Code Example: The Append Disconnect ```go package main import "fmt" func main() { // Slice with length 2, capacity 5 mySlice := make([]string, 2, 5) mySlice[0] = "Stay" mySlice[1] = "Stay" attemptAppend(mySlice) fmt.Println("Original Slice Length:", len(mySlice)) // Output: 2 fmt.Println("Original Slice Data:", mySlice) // Output: [Stay Stay] // Note: The data "Added" IS in the array, but the caller's // length field prevents us from seeing it. } func attemptAppend(s []string) { s = append(s, "Added") fmt.Println("Inside Function:", s) // Output: [Stay Stay Added] } ``` ### The Solution: Returning the Slice Because the slice header is passed by value, any operation that modifies the header itself (like changing the length or reallocating the pointer via `append`) must be communicated back to the caller. The standard Go idiom is to **return the updated slice**: ```go func main() { mySlice := []string{"Alpha"} mySlice = successfulAppend(mySlice) fmt.Println(mySlice) // Output: [Alpha Beta] } func successfulAppend(s []string) []string { return append(s, "Beta") } ``` Alternatively, you could pass a **pointer to the slice** (`*[]string`), which allows the function to modify the caller's header directly, though returning the slice is generally considered cleaner and more idiomatic in the Go community. # Laravel # Suggested Learning Path - Install + run first Laravel app - Routing + controllers + Blade views - Forms + validation + CSRF - Database + Eloquent + migrations + seeders - Auth + middleware + policies - Build a small CRUD app (final project) - If you want, I can set up a Laravel Sail project in this workspace now and start Lesson 1 immediately. # Links and Resources [https://laravel.com/docs/12.x/](https://laravel.com/docs/12.x/) Laraval Sail