Formidable Blog

> There is so much indirection between the sagas and reducers and the effects. Like, I just want to see the code that actually does all the work. I understand the sagas "look" easy, but that's just because all the good stuff is hidden away. I like to see easily where the rubber meets the road, so to speak.

So do I, which is why I dug into it a bit deeper before using it on a project. This article is actually the third in a series (see [1] and [2]), and the first one goes into a little bit of detail about how things work behind the scenes.

> The put/call/takeLatest/takeEvery effects, coupled with all the yields made things impossible to grok for the less seasoned folks.

I definitely feel you on this, and it's _very_ easy to let things get out of hand. I'm very much _not_ a fan of nesting an anonymous generator function inside takeEvery/takeLatest; it's just too easy to start accessing variables from the enclosing scope and then everything gets totally FUBARed.

> It's been several months since I worked on that code, and it's all Angular 2,4,a billion all the time now, so I apologize for limited specifics. In general I appreciate that people are trying new async things (CSP, sagas, observables etc) but they all just feel like a fad to me. Obviously use the right tool for the job, but most of the time I think promises should be the way to go unless there's a super compelling reason not to.

This is totally fair, and I definitely agree that apps should start with simple tools…

I really like the simplicity of the core library and this approach of starting from a simple core and building on top of it with the same primitive for extensibility as the one you offer to users.

Apollo has also been moving in this direction with composable links, but in a zig-zaggy way since it's still got some baggage from its days as a monolithic library, and recent decisions to move local state management into core seems to be backtracking from that effort somewhat, so it's great to see some competition in this area that really approaches extensibility as a first class citizen rather than an afterthought.

With that said, I'd love to see an officially supported normalizing cache implementation as well, in addition to the simple document cache Urql currently provides as a default:

https://formidable.com/open-source/urql/docs/basics/#code-classlanguage-textcacheexchangecode

Apollo and Relay's normalizing cache helps ensure a single source of truth for every piece of server data, which is incredibly valuable for non-trivial apps that have the same pieces of data fetched in multiple places that would otherwise have to be manually kept in sync, which anyone who has ever tried to do so can tell you is generally extremely tedious, error prone, and likely a frequent contributor to user-facing bugs. That to me is by far the most compelling value prop of GraphQL clients like Apollo and Relay. It'd be great if I didn't have to choose between automatic normalization and a more…

I have spent a lot of time looking in this space recently for helping to revamp documentation and I really really have fallen in love with Markdoc.

Markdoc just hits the sweet spot of being super easy to get started with but elegantly extensible that makes it scale. I think the OP here simplifies a bit though of what Markdoc is. While it is pretty simple to integrate into a next.js site for a SSG doc site, it is more of a library that can be integrated into almost any site or rendering framework.

In some ways, this is the biggest "challenge" of Markdoc right now. It isn't focused on a polished out-of-the-box experience like Docusaurus or MKDocs, but is instead more of a DIY tool.

That said though, what is there is really great. With the ability to create custom tags easily and then the ability to analyze and transform an AST in a simple, but easy to understand way, I think markdoc is actually a great option for more than just building a doc site, but as a more general purpose tool for authoring any text-heavy content.

With Markdoc, I have built:
* a higher level utility for creating a "library" of content with consistent ids for stable and validated links
* a validation library to ensure that doc structures follows best practices like having metadata tags in the frontmatter, properly nests headers and doesn't skip H3s, etc
* an integration for authoring and reusing doc content in spectacle[0] presentations
* have a clear direction of how to "scale" docs-as-code as we…

The archetype terminology comes from the use of Builder; you can get a rundown of what an archetype really is here, independently of its usage in Electrode: https://formidable.com/open-source/builder/

Framework and app generator are really quite far off from what an archetype provides. An archetype is like an npm module template, but not one that is used to generate code files and then discarded, but more like a live "superclass" of a module; think inheritance but for npm modules.

The basic idea is that if you have dozens or hundreds of similar modules (for, say, React components), with similar build + testing needs, you can use the same archetype for all of them. A generator like yeoman could spit out boilerplate for you, but then what if your boilerplate changes? Your packages quickly get out of sync with your latest best practices. Having some components on Babel 5 and some upgraded to Babel 6, for example, was a real pain. You have to go through your dozens of packages and bring them up to date. Archetypes on the other hand are intended to be encapsulated boilerplate that packages basically "inherit" from at runtime.

Hope that helps!

While you check out this very cool repo on Formidable's Github, if you're interested in React and/or data visualization, be sure to also check out their Victory React dataviz project, and accompanying charts library.

Victory is somewhat similar to what we discussed putting together as the underlying React-based dataviz library for our react-d3 chart library, except they seem to be figuring out a nice animation API where we struggled.

I ended up burning out from (both paid and open source) overwork last year, and never got my (very basic) dataviz library code out the door, but I'm incredibly impressed with the comprehensive library Formidable has come up with[0], with lots more to come it would appear. I'm easing back into open source work now, but it's pretty clear there's no longer a need for a good low-level, React-based dataviz library.

If you're looking for an interesting new dataviz library to check out, take a look at Victory.

0. https://formidable.com/open-source/victory/

SEEKING FREELANCER | Boise| Remote | US Time Zone

Hello, I am looking for someone with react native and chart library expertise (such as Victory - https://formidable.com/open-source/victory/) to create a real-time polar chart with X, Y and Z axis that would represent pitch, yaw and roll.

The chart would show the current value of pitch, roll and yaw (i.e. real-time data point need to be displayed only and no historical data plot). The chart should be performant for real-time tracking (i.e., around 50-100 data points per second). Also, the range of the X, Y, Z axis should be adjusted so that it is easier to see these 3 values when there is a movement. (please message me if you have questions on the last statement).

Thank you for looking into this project.

--Nat
natarajkg@yahoo.com