Closed far-blue closed 6 years ago
I don't think that you can mix them. Go for NestedTypes 2.0, which is based on the last Type-R core. It's rather thin and simple extension over Type-R adding BackboneJS API compatibility layer.
Still, it exports Record
class from Type-R untouched.
In the end for the project in question we stuck with NestedTypes 1.x. We'll handle the upgrade to NestedTypes 2.x first and then investigate a possible switch to Type-R :)
An upgrade might be quite challenging because 2.0 introduce strict ownership policy, distinguishing aggregation and references to shared objects. Not a big deal for domain models, but might be tricky for the UI state models. Don't hesitate to ask for the help.
It worths an effort, though. It's noticeably faster and memory efficient because it's heavily optimized to work with aggregation trees, introduce no memory leaks due to accurate aggregation tree disposal, and clone()
operation is guaranteed to be correct on the complex object trees.
It makes sense to switch to the raw Type-R if you don't need underscore, jQuery, and Backbone objects like View, Router, etc. Type-R didn't have IO layer, but it's about to change within weeks.
Version 3.0 which we're starting to work on very soon will not modify any globals by default, so yes, it could be mixed with older versions.
Btw, Type-R version 2.1 supports restful IO, so there are no any reasons to use NestedTypes feature-wise. Just for backward compatibility.
Implemented in the upcoming version 3.0 (develop
)
Hi :)
Some of our shared packages use NestedTypes 1.3 and we are not yet in a position to refactor them to use Type-R or NestedTypes 2.0 (depending on what best fits). However, we do want to start using Type-R for page/app specific state. Can you think of any problems? I was thinking maybe the Store functionality might conflict, for instance.