- Learn better - i already used Livewire, but only for a few features at work and in university projects - how to integrate Laravel/Livewire with third-party libraries involving report-generation/charts - latests tasks on my internship involved these kind of features.
- Understand better the relationship between AlpineJS and Livewire - these two are used in the "TALL" stack
- See good practices from Povillas (the instructor) on how he works around limitations of integration between libraries and the framework (e.g: CKEditor, Select2...)
- Get aware of multiple dynamic behaviors that can be implemented in UI - multiple would be showed in basically each feature in this course - and if it is worthwhile or not (e.g: sorting on drag-and-drop is too much overhead for a result that almost always useless... Sorting on column though is interesting in some scenarios.
The solution i usually take in the "project-courses" is mentioned below.
PS: In this course specifically, some of features from third-party libraries i wasn't aware how to make them work on my own and struggle to find how. In these difficulties i've asked in the instructor's community about information and was guided by answers from more experienced developers. So that's why a lot of the classes mentioned in the commits have the "instructor's version" and no more versions about it.
- Reach myself a solution - with some extra glow or not - for the lesson based on the professor's solution - if any
- Compare my approach to the professor's
- Implement professor's solution
- Repeat last steps with the next class
Currently in my work i deal with projects involving multiple people, and specifically applications that either are mantained for a long time (20-30y), or on the build of newer version of them using modern frameworks.
Frequently i don't get solutions for the problems i face in a pass of magic (the most near to this is, by understanding the business rule around the feature, get a base-solution from LLMs). So i found better, after the initial configs have been set - e.g: how the routing is dealt -, to try my own approach in each class - each class is a feature generally.
And besides that, why implement my own version based on previous versions of features based on the professor's version? Well, simlar reason: working with others implies developing based on previous code not always written by yourself, so developing based on the professor's approach intends to simulate the real-world scenario i pass daily in work.
My own solution can include additional aspect not asked by the professor. Below are a few examples from this project:
- Take approaches to solve problems solely with Laravel/Livewire in situations that the instructor would add up AlpineJS
- Implement error-handling in places where it lacked in instructor's version
- Couple small components to reduce overhead without damaging maintenancy - check commit f64250d00b544fbf634962cdb39c1a98848c4f74
Why a lot of "mixed with instructor's version" and some solely "my version" are mentioned in the commits?
Some of the approaches taken by the instructor really didn't provided any improvement and i decided not to take strictly my methodology, avoiding letting all "pure" changes by the instructor in each step, mixing up with some decisions of mine.
E.g: "Delete selected" -> I'd disable this button and change its style based on `empty($productsSelectedToBeDeletedIds)`; the instructor would create a computed property in the component to calculate this upon another property, `selected`. My naming is better, the computed property doesn't provide any improvement due to perform a simple calculation.