http://epydoc.sourceforge.net/api/ - epydoc has great combination of reference documentation combined with codebase visualization. Please note that the two visualisations in "Package epydoc" and "Package Organization" ar both clickable. Once clicked, also feel free to find and click "call graph", which itself visualizes, well, call graph.
Sadly epydoc is no longer maintened and only supports py2. Had an idea of porting it to py3, but never found enough time to do so.
The biggest thing I miss in react ecosystem is decent redux ORM. https://vuex-orm.org is just so great for so many use cases (agree that it might an antipattern in many situations). Is there any chance that https://github.com/redux-orm/redux-orm, which was actually what inspired vuex-orm, would get more love from anyone to become an actively maintained library?
Great question. I actually was one of the earliest users of Redux-ORM, back when I myself was first learning Redux in 2015-16, and I wrote a blog tutorial series in 2017 that showed how to use it.
At the time, the main benefits to using Redux-ORM were easier immutable updates for items in the store, keeping items in a normalized state structure, and managing relationships between items for both lookups and updates.
Since then, Redux-ORM has changed maintainers and had its API tweaked. Meanwhile, we added a `createEntityAdapter` API [0] to RTK, which handles normalization and some CRUD-style updates to the data. Even without those CRUD helpers, you can still do `state.entities[itemId].someValue = 123` thanks to Immer, so immutable updates are taken care of.
At this point, the one remaining thing that Redux-ORM really handles that RTK doesn't is that specifically relational behavior - ie, given a `Post`, look up all its `Comment`s by an array of IDs or something. You can do a decent amount of that with selectors, but yeah, Redux-ORM's API here is nicer.
We haven't tried to provide any of that ourselves because this becomes a much more complicated and app-specific topic. But, I'm always open to suggestions for APIs and use cases. If you have ideas for things that we should consider adding to RTK, please do file an issue so we can discuss details!
I've been reading "blue" DDD book (by Eric Evans) and "red" book (by Vaugh Vernon) and that was a completely "my whole life was a lie" type of experience and relief at the same time. It's just so great to have the principles of who to structure the code. It, by definition makes, your codebase structure meaningful. Because it's structured according to some common knowledge, not your random thoughts at the time you were writing code.
I was surprised to find so little DDD react sample codebases. Let's say for backend there is huge amount of samples, i.e. https://github.com/kgrzybek/modular-monolith-with-ddd . For react/frontend I have bookmarked only https://github.com/talyssonoc/react-redux-ddd/tree/master/sr... and few more, but those others does not meet the optional criteria i like really much - at the highest (or at app) level all codebase need to have folders app, domain, infra and ui. Simple rule, but simplifies life a lot.
So my question is - is DDD for some reasons not very applicable for app frontend development. Or it just never became popular. Or maybe DDD is popular amongst react developers, just I am not aware of this.
Would love to see you guys partnering with TailwindUI somehow. That's my default go-to ui widgets library (it's not open source, so it might be challenging to find a proper partnership model with them).
Just bought a lifetime subscription. And as I already do have subscription - my last recommendation is to switch to monthly subscription model as soon as you can. Monthly subscriptions is just so much more profitable pricing model:)
You used to be able to import TailwindUI’s components to Shuffle’s VSCode extension, but I’m not sure if that is still the case (or if it was ever condoned).
Hey, we allowed uploading Tailwind UI (as a ZIP archive) into our editor if you had a license and access to sources. Of course, we didn't sell access to their library.
We will open this feature to any UI library in the future. However, we put it on hold because (1) it supports just one format (ZIP archive with category -> components in separated HTML files), (2) development of our UI libraries is more important to us at this moment :)
Oh yes, didn’t mean to imply it was anything nefarious and I really enjoyed having that flexibility/using your product! Have had a lifetime license for around 6 months now and you guys are doing a great job!
It was not really a website generator when in the VSCode extension. It was more of a copy and paste into your editor, with a easier way of viewing the components available (e.g., via dropdown in the editor).
Sad to see a very concise comment revealing arguably the deepest and biggest problem of the frontend world - frontend architectures naming problem - being downvoted.
Swithing between the two periodically every month. I think you just get tired of looking in many tasks in the same interface, that's when I do the switch :)
In performance marketing(=KPIS are a)sales volume and b) Cost per action - CPA) it's very simple - you can't scam how much you've spent on ads. Also you can't scam how much you charged the traffic you've bought. Both figures are reported by your finance department with pretty much 100% precision.
Yes, you do have a challanging problem of attribution. But the spend and revenue figures are what matters at the end of the day. And neither of them has any area for scamming (let's ignore edge cases).
Disclosure: only skimmed through the article and my arguments above are just directed towards the headline. However credible and opinion leader the author - Rand Fishkin - is, the article itself at the first glance did not inspired me personally as a worthy my attentive reading time.
If you discredit the article's argument by the headline, what's the point? Everyone may do exactly that to your comment and opinion: at first glance it did not inspire me as worthy of my attentive reading time.
C'mon, this ain't reddit. Don't comment without reading.
For those looking of component showcase i'd kindly advise to also look at https://bit.dev, https://github.com/teambit/bit . It is a standalone service that hosts your components, providing each of it as a npm package.
You end up developing the components in a separate repo, and in your main app repo you install each component as dedicated npm package. Those who get excited by `separation of concerns` pattern should find this a real joy.
I took a look at that, and it's completely incomprehensible to me why I should use it and what actual benefits I get for adding all this extra tooling and complexity as compared to just having a company monorepo for reusable components.
I’m very big on the monorepo approach and it’s benefits so that will be a pass for me.
I like to be able to modify my component and immediately (one hot reload) be able to modify a site of use of this component one second later. Having 1+min of npm publish and npm install get in the way is not what I want.
But I can understand the utility for some different use cases.
Sadly epydoc is no longer maintened and only supports py2. Had an idea of porting it to py3, but never found enough time to do so.