2 ms·

Introducing Remodel – A tool for building and managing iOS model objects

5 points by andrewcuneo 11y ago

andrewcuneo 11y ago
Hi, my name is Andrew and I'm part of the team that just released a new open source tool from Facebook called Remodel. It's a tool for people who write Objective-c and want to use immutable value objects in their code, which can be a pain to manage. This is a tool we've had around for a long time in our fbobjc codebase and it's something we've found very useful. I've lurked on HN for a while, but am new to posting and commenting, so I'm looking forward to answering some questions.
- natch 11y ago
  Thanks for sharing. I do have some questions, probably ones coming out of almost unfathomable ignorance, but hope you can answer. Any plans for supporting Swift output? Or is that question completely missing the point of this tool (like, maybe with Swift its support for immutable value objects is already so good you don't need this?) What is a .ts file? Could this have been done instead with a new mogenerator template, or what is the limitation of mogenerator that would have prevented that? Could this help with creating code for attributes with the Transformable data type? I see there is a tiny bit in the readme about the workflow, but nothing about how that fits in to the usual Xcode workflow for working with models and their associated classes (in Xcode the word model refers to the xcmodel file(s) I believe, not the code, but you're using it in a more general way). What would be the Xcode workflow for using this, starting from an empty project with no xcmodel file, and proceeding until it's done?
  - andrewcuneo 11y ago
    I had almost given up on getting any traffic here. So, I'm excited that I got some good questions. Let me try to answer them. 1. It is kind of a bummer that we don't support Swift. As silly as it is, probably the main reason for this is that at FB we only really code in ObjC (at least for the near term), so we wouldn't have any local use cases (which both drive our development and help us validate that the concept is useful). It is also true that the need for this type of system is a lot greater in ObjC. Like you said, Swift is awesome in terms of its support for immutable objects and it even supports something a lot like ADTS out of the box (they call them "Associated Values" in their enums). Because Remodel makes these nice concepts available in Objective-C, it's a useful tool for people who like Swift but are, for whatever reason, working in a Objective-C codebase. Also, at some point we may make a Swift output option and it would have value in terms of the plugins that can make simple operations like encoding / decoding or other basic helpers. 2. A .ts file is a TypeScript file, which is a language that Microsft developed which compiles to JavaScript. TypeScript looks a lot like JavaSript, but it has types. We chose TypeScript for the implementation of Remodel because we liked the fact that it's based on JavaScript which is extremely popular, well-known, and also suited toward functional programming. TypeScript uses JavaScript's familiar syntax but adds compile-time support for strong types and generics, filling in one of the major gaps in the language. 3. I actually wasn't aware of mogenerator -- but looking through it, I can see that there is some overlap and also important differences. One of the best benefits of Remodel is that once you start generating your models through it, people cannot add custom code to them. This lines up with a big section in the blog about architecture ("Modeling Your Architecture"). To sum it up here: there are a lot of benefits to keeping models completely free of custom logic and instead putting that logic into behavior classes. In mongenerator, however, it appears that every entity gets a subclass to add custom code, which is at odds with this philosophy. There are also some differences around the focus on CoreData in mongenerator while Remodel objects are completely free of assumptions about how they're stored, transported, etc. 4. Remodel generates simple encode/decode methods for you out of the box, and the plugin system we have could allow you to generate other transformation logic for your models. I honestly don't work with CoreData that much, so I'd need more details to give a better answer to this question. 5. You're right that we're not talking about xcmodels here. Overall, Remodel objects operate very much as vanilla Objective-C objects, so the workflow is pretty basic and familiar: * Create a .value file, for example MyModel.value: MyModel { NSString *prop1; } * Run '$ remodel-gen MyModel' * This yields 2 new files (MyModel.h and MyModel.m) * Add MyModel.h and MyModel.m to your project * Make behavior classes that use the Model for something interesting * That's pretty much it :) There's no support right now for going back and forth between a .value file and a CoreData .xcmodel file. In theory that shouldn't be too hard to create if there's demand for it.
    - natch 11y ago
      Cool, thanks for the great reply! That makes it much more clear. I'll look for the blog post you mentioned. Edit: oh duh it's the original link of the post I guess. (I had originally come here from the a github link which I thought was a dupe of this post, so I was confused... asked my original questions having seen only the github project).

5 points by andrewcuneo 11y ago

Hi, my name is Andrew and I'm part of the team that just released a new open source tool from Facebook called Remodel. It's a tool for people who write Objective-c and want to use immutable value objects in their code, which can be a pain to manage. This is a tool we've had around for a long time in our fbobjc codebase and it's something we've found very useful. I've lurked on HN for a while, but am new to posting and commenting, so I'm looking forward to answering some questions.

natch 11y ago
Thanks for sharing. I do have some questions, probably ones coming out of almost unfathomable ignorance, but hope you can answer. Any plans for supporting Swift output? Or is that question completely missing the point of this tool (like, maybe with Swift its support for immutable value objects is already so good you don't need this?) What is a .ts file? Could this have been done instead with a new mogenerator template, or what is the limitation of mogenerator that would have prevented that? Could this help with creating code for attributes with the Transformable data type? I see there is a tiny bit in the readme about the workflow, but nothing about how that fits in to the usual Xcode workflow for working with models and their associated classes (in Xcode the word model refers to the xcmodel file(s) I believe, not the code, but you're using it in a more general way). What would be the Xcode workflow for using this, starting from an empty project with no xcmodel file, and proceeding until it's done?
- andrewcuneo 11y ago
  I had almost given up on getting any traffic here. So, I'm excited that I got some good questions. Let me try to answer them. 1. It is kind of a bummer that we don't support Swift. As silly as it is, probably the main reason for this is that at FB we only really code in ObjC (at least for the near term), so we wouldn't have any local use cases (which both drive our development and help us validate that the concept is useful). It is also true that the need for this type of system is a lot greater in ObjC. Like you said, Swift is awesome in terms of its support for immutable objects and it even supports something a lot like ADTS out of the box (they call them "Associated Values" in their enums). Because Remodel makes these nice concepts available in Objective-C, it's a useful tool for people who like Swift but are, for whatever reason, working in a Objective-C codebase. Also, at some point we may make a Swift output option and it would have value in terms of the plugins that can make simple operations like encoding / decoding or other basic helpers. 2. A .ts file is a TypeScript file, which is a language that Microsft developed which compiles to JavaScript. TypeScript looks a lot like JavaSript, but it has types. We chose TypeScript for the implementation of Remodel because we liked the fact that it's based on JavaScript which is extremely popular, well-known, and also suited toward functional programming. TypeScript uses JavaScript's familiar syntax but adds compile-time support for strong types and generics, filling in one of the major gaps in the language. 3. I actually wasn't aware of mogenerator -- but looking through it, I can see that there is some overlap and also important differences. One of the best benefits of Remodel is that once you start generating your models through it, people cannot add custom code to them. This lines up with a big section in the blog about architecture ("Modeling Your Architecture"). To sum it up here: there are a lot of benefits to keeping models completely free of custom logic and instead putting that logic into behavior classes. In mongenerator, however, it appears that every entity gets a subclass to add custom code, which is at odds with this philosophy. There are also some differences around the focus on CoreData in mongenerator while Remodel objects are completely free of assumptions about how they're stored, transported, etc. 4. Remodel generates simple encode/decode methods for you out of the box, and the plugin system we have could allow you to generate other transformation logic for your models. I honestly don't work with CoreData that much, so I'd need more details to give a better answer to this question. 5. You're right that we're not talking about xcmodels here. Overall, Remodel objects operate very much as vanilla Objective-C objects, so the workflow is pretty basic and familiar: * Create a .value file, for example MyModel.value: MyModel { NSString *prop1; } * Run '$ remodel-gen MyModel' * This yields 2 new files (MyModel.h and MyModel.m) * Add MyModel.h and MyModel.m to your project * Make behavior classes that use the Model for something interesting * That's pretty much it :) There's no support right now for going back and forth between a .value file and a CoreData .xcmodel file. In theory that shouldn't be too hard to create if there's demand for it.
  - natch 11y ago
    Cool, thanks for the great reply! That makes it much more clear. I'll look for the blog post you mentioned. Edit: oh duh it's the original link of the post I guess. (I had originally come here from the a github link which I thought was a dupe of this post, so I was confused... asked my original questions having seen only the github project).