Introduction
Writing code that's both easy to test and easy to read can be a challenge, especially with Vue components. In this blog pos...
For further actions, you may consider blocking this person and/or reporting abuse
I like this article very much. The seperation of the business logic really suits me well. It leans in a DDD direction of usecases I think.
github.com/attikos/ddd-vue-match-game this is taking it even further.
Thank you for your comment. The Imperative Shell/Functional Core pattern aims to leverage the best aspects of functional programming and pure functions without the complexity of other concepts, such as how functional programming deals with side effects using monads. You can argue that all these architectural designs always have the main topic of separating core business logic and creating layers that aid in maintainability. I also find Domain-Driven Design (DDD) interesting and need to learn more about that.
Very interesting approach! I think I already use this way of thinking on the React ⚛️ side (without putting a name to it...) I will extend this approach to other reactive frameworks ;) Thanks for sharing 🙏
I loved the article! Recently, I discovered Hexagonal Architecture as a way to separate business logic from the UI. I wanted to tidy up a feature in my Vue app to make it easier to test automatically. I managed to do that, but I think the team found it a bit overwhelming, especially the object-oriented structure I introduced. This approach seems simpler yet achieves the same results.
To be honest, I still like the OOP approach, but I want to keep things as simple as possible.
Yes, thank you for the comment. There are many ways that can help us in the frontend world to write better, maintainable code. I have the feeling that the frontend has become more complicated over the years, but we don't use useful tools to structure our applications like they do in the backend world with clean architecture or hexagonal architecture. The simplest thing is to have a consistent folder structure and extract business logic into .ts files that don't have any dependencies and would work in any framework.
Would it make sense to also externalize the canvas logic? Since that is also framework agnostic.
Hmm, I'm not sure about that. In the end, you can extract and put in new layers; only time will then tell if it had any benefit.
It is very good, however the change in the code of the main component was not much. It is still a bit long and dirty. The advantages you mention are 3. I for example do not use tests in the frontend, and it is unlikely that someone in your project changes Frameworks often, the only strong point I see is that it improves maintainability, and the latter is strong enough to use this approach. Where can I learn more about this topic? Any courses? A book? Or more articles? Thanks
Thank you for your comment. In a blog post, it's hard to find a good example to explain the idea. But in my experience, this pattern can really help with readability. You can Google the "Functional Core, Imperative Shell'" pattern; there are more articles out there for different languages. Also, what helps is to learn a functional programming language like Haskell, then you see the beauty of pure functions more. Unfortunately, for the frontend world, there are not many good books or courses about architecture design ideas out there. For backend, there are many, like Clean Architecture, Hexagonal Architecture, etc.
You can also try fsd(feature sliced design). I think this is really good for large projects and clean code.
Any good resoruce to learn FSD. Please share if you know.
found this maybe it will help you
blog.stackademic.com/frontend-mast...
Thanks. Nice article but still practice is important.