Thanks for your response.
I just bought xD
jesusangelm
AstonJ
otuv
shifters98
With Dave’s new component library just released - I am intrigued - i have his book (and many others 
) - this has lead me here as i want to learn his approach to elixir coding in particular the component and decoupling. Thanks all for the drawing my attention here.
1
Fl4m3Ph03n1x
The main reason I am quite reluctant into buying his course is because none of his ideas gained traction. I am talking about his opinions about components, libraries and even Noddy.
All seemed good ideas overall, but after spending hours reading community feedback they just don’t hold. And this is what scares me.
Can anyone give me feedback on my fears? Are they valid, or does he present something else, something new?
0
abitdodgy
I haven’t taken the course, so I can’t give any useful feedback. Can you show me some specific examples where his ideas have failed to gain traction in the community?
0
Fl4m3Ph03n1x
A small set of opinions regarding his component library (there is a huge one with over 100 posts but I forgot its name):
His Noddy library that didn’t really took off:
0
peerreynders
That topic is about the ideas as proposed in the Empex 2018 Keynote.
The course predates that particular “component” development. It is my sense that the idea in the course is much simpler - favour decoupling. To that end “components” and OTP applications are synonymous for the purpose of the course - the Empex 2018 keynote added tooling/infrastructure for a particular implementation flavour of the component idea to move away from the Erlang/Elixir centric configuration practices (and templates on top of GenServer).
The course takes a much simpler approach - ignore Phoenix contexts and mix umbrella projects and use parallel application (Poncho projects) dependencies instead. It’s a valid approach but a lot of people are loath to give up the convenience that Phoenix contexts and umbrella projects afford them.
The resulting structure can be seen here
https://github.com/pragdave/e4p-code
Hangmanis the game (business) “component”.TextClientthe command line clientGallowsthe Phoenix web frontend that uses the game “component”.
3
Fl4m3Ph03n1x
Ha ! A critical piece of information. I will put this on radar for sure now that I know he doesn’t push component in the course 
0
peerreynders
The more recent idea that failed to gain traction so far is encapsulating state inside of processes much in the same way that OO objects encapsulate/hide state.
He critizes the following state access and manipulation pattern:
# game is a struct
game = %Hangman.State{} |> Hangman.choose_word_to_guess
game.word_so_far
game.letters_guessed
game = Hangman.score_guess(game, guess)
In particular game.word_so_far and game.letters_guessed expose implementation details of the state which leads to inappropriate coupling. So he prefers
# game is a pid
game = Hangman.create()
Hangman.word_so_far(game)
Hangman.letters_guessed(game)
result = Hangman.score_guess(game, guess)
i.e. the implementation details of the state are hidden inside the process. However this is seen by some as an abuse of processes, pushing towards the “a process is an object instance” model.
As it is, this is possible today without processes with a “hands off my state” coding discipline:
# game is a struct
game = Hangman.create()
Hangman.word_so_far(game)
Hangman.letters_guessed(game)
{result, game} = Hangman.score_guess(game, guess)
And dialyzer even supports an opaque type:
Types declared as
opaquerepresent sets of terms whose structure is not supposed to be visible from outside of their defining module. That is, only the module defining them is allowed to depend on their term structure.
The problem is that doesn’t stop anybody from depending on or messing with the state’s internal structure.
What would be needed is a capability to mark structs as opaque and have the compiler enforce it.
The idea is actually in place. game.ex manipulates the game’s data structure while server.ex encapsulates that state. All of that is wrapped inside the Hangman OTP application and each game instance is identified by a pid. Phoenix stores that pid in the session.
But given the application level decoupling that pid could be replaced by some other form of game_id to be managed in another way.
3