Hello, I also implemented Tic-Tac-Toe in Elm. https://ellie-app.com/g8VstS3hq2pa1.
For stopping me to hard-code some functions, I also implemented some buttons to change the size of the game-board.
Are there any ways to make this simpler and more straightforward? I think the updating of the board is complicated compared to an imperative solution.
I also wanted to ask, whats the best way to split this up in smaller files. Most of the functions need some of the custom types declared at the beginning. But I read, that it s bad style to share these Types in one file.
Then when you’re drawing the board if the (row, col) is not in the dictionary then neither player has played there yet. Adding a move to the board is just a Dict.insert (row, col) player.
If you wanted to do undo/redo, you just need to store the list of (row, col) moves and removing a move is just a Dict.remove (row, col).
Hi @brucesp. Regarding how to split your code, modules should be organized around data structures. Like in elm/core where you have the List or Dict modules but this is true for any data structure, not only collections.
Doing so enables making a clear frontier between what is handled privately inside the data structure and what is exposed publicly.
For the logic, you can basically just put the code where it’s the most convenient, usually closer to where it’s used. It’s not a problem at all if one file starts getting really big with logic, since the compiler is your friend and will catch most of your mistakes. I’d avoid splitting a file, just because it’s getting big.
I think simplifying some type annotations would be an improvement. For instance, once you have defined your Model type, why not use it in init, initHelper, view.
Also, I would say your viewHelper function could be merged in your view. After all, view does little more and that means less jumping around for the reader.
For what it’s worth, the reviews I received for my Tic-Tac-Toe code resulted in more logic in my view function (but less nested function calls).
I thought about that, I thought, that would make the drawing and checking the winning condition more difficult.
I think simplifying some type annotations would be an improvement. For instance, once you have defined your Model type, why not use it in init , initHelper , view .
Yes, that makes everything more readable. I changed that. Thank you very much.
