Patterns.dev
patterns.dev
Patterns.dev
1–10 of 158 posts
Re: Patterns.dev
#2Thanks, I was looking for something just like this today!
Re: Patterns.dev
#3I was glancing around and landed on the page for the flyweight pattern.[1]
It looks like `addBook` is using the spread operator, which always creates a shallow copy of the book instance properties, thus nullifying any benefits of the flyweight pattern. It also attaches extra arbitrary properties, but still assigns the result to a `book` variable. I don't think this is a great example.
[1]: https://www.patterns.dev/vanilla/flyweight-pattern/
Edit: I forgot to give you kudos for all the effort it must have taken to create all this content, and I appreciate that you're making it available for free.
Re: Patterns.dev
#4Love this! Just wanted to note that I think there’s a mistake on the flyweight pattern page’s example. You’re using getting a boolean with Set.has but treating it like a Book (as if you had used Set.get). I also don’t really understand how this saves memory if you’re spreading the result into a new object, but maybe someone here can enlighten me!
Re: Patterns.dev
#5Love this! Just wanted to note that I think there’s a mistake on the flyweight pattern page’s example. You’re using getting a boolean with Set.has but treating it like a Book (as if you had used Set.get). I also don’t really understand how this saves memory if you’re spreading the result into a new object, but maybe someone here can enlighten me!
Ah I think I understand now. The return type of createBook is true | Book, which is likely a mistake, but happens to work because when you attempt to spread a boolean into an object it removes itself. But if you were to edit the example to have a stable return type of Book then it would no longer save memory, so perhaps that was intentional?
Re: Patterns.dev
#6Looks great, time to add it to my bookmarks.
Anyone has other sites like these to share?
- Domain-driven design, design patterns, and antipatterns
- Refactoring and Design Patterns
- Standard Patterns in Choice-Based Games
https://heterogenoustasks.wordpress.com/2015/01/26/standard-...
Re: Patterns.dev
#7The ones that actually match POSD (deep modules, small interfaces, lower complexity) and work great with plain functions are:
Module Pattern
Factory Pattern (factory functions)
Mediator / Middleware Pattern (as function pipelines)
Hooks Pattern (custom hooks, generalized)
Container / Presentational Pattern (implemented with function components + hooks)
Everything else is either neutral, UI-only, or fights POSD (Singleton, Mixin, etc.).
Patterns from that page you should treat skeptically for POSD
From Patterns.dev, for your POSD-style codebase I’d avoid or downplay:
Singleton Pattern → encourages global state and tight coupling. Patterns
Mixin Pattern → tends to increase interface surface and make dependencies opaque. Patterns
Observer Pattern → powerful, but event-based wiring can obscure data flow and increase “system complexity” (classic POSD warning). Patterns
Re: Patterns.dev
#8[deleted]
Re: Patterns.dev
#9Looks great, time to add it to my bookmarks. Anyone has other sites like these to share? - Domain-driven design, design patterns, and antipatterns https://deviq.com/ - Refactoring and Design Patterns https://refactoring.guru/ - Standard Patterns in Choice-Based Games https://heterogenoustasks.wordpress.com/2015/01/26/standard-...
I’ll make a plug for aep.dev, which is a collection of API design best practices and assorted tooling
Re: Patterns.dev
#10Looks great, time to add it to my bookmarks. Anyone has other sites like these to share? - Domain-driven design, design patterns, and antipatterns https://deviq.com/ - Refactoring and Design Patterns https://refactoring.guru/ - Standard Patterns in Choice-Based Games https://heterogenoustasks.wordpress.com/2015/01/26/standard-...
- Java Design Patterns