facebook / remodel Goto Github PK

AlgebraicType {
  TypeA
  TypeB {
    NSDictionary<AlgebraicType *> *algebraicTypes
  }
}

produces:

#import <Foundation/Foundation.h>

typedef void (^AlgebraicTypeTypeAMatchHandler)();
typedef void (^AlgebraicTypeTypeBMatchHandler)(NSDictionary<AlgebraicType *> *algebraicTypes);

@interface AlgebraicType : NSObject <NSCopying>

+ (instancetype)typeA;

+ (instancetype)typeBWithAlgebraicTypes:(NSDictionary<AlgebraicType *> *)algebraicTypes;

- (void)matchTypeA:(AlgebraicTypeTypeAMatchHandler)typeAMatchHandler typeB:(AlgebraicTypeTypeBMatchHandler)typeBMatchHandler;

@end

I tried this:

%library name="simd"
%type name=vector_int2 library=simd canForwardDeclare=false
MyObject {
  NSString *identifier
  vector_int2 position
}

Output:

[error][Thu Jan 24 2019 15:31:14 GMT-0500 (Eastern Standard Time)] [/REDACTED/Broken.value]The Description plugin does not know how to format the type "vector_int2" from MyObject.position. Did you forget to declare a backing type?
[/REDACTED/Broken.value]The Equality plugin does not know how to compare or hash the type "vector_int2" from MyObject.position. Did you forget to declare a backing type?
Successfuly generated 0 objects. Encountered 1 errors in other files

Based on the documentation for a value type, it seems like I can declare an "underlying" type, but vector_int2 can't be composed out of the builtin types.

How do I tell remodel that it's a value type you can compare with == and copy with =? Does this require changes to remodel-gen to support?

What's the main difference and pros/cons between Remodel and Plank? Have you guys done any testing or comparison?

Both seems quite similar and have the same goal, generate immutable models.

try to generates the sample value file encounter a error:

remodel-gen ~/desktop/AddressBookContact.value

/usr/local/lib/node_modules/remodel-gen/bin/dist/js/object-mona-parser/value-object/value-object-parser.js:32
foundType: parsedType
^

ReferenceError: parsedType is not defined
at Object.parse as parseValueObject
at Object.parse (/usr/local/lib/node_modules/remodel-gen/bin/dist/value-object-parser.js:72:35)
at evaluateUnparsedValueObjectCreationRequest (/usr/local/lib/node_modules/remodel-gen/bin/dist/value-objects.js:31:41)
at right (/usr/local/lib/node_modules/remodel-gen/bin/dist/either.js:46:39)
at match (/usr/local/lib/node_modules/remodel-gen/bin/dist/either.js:34:16)
at Object.mbind (/usr/local/lib/node_modules/remodel-gen/bin/dist/either.js:47:12)
at parseValues (/usr/local/lib/node_modules/remodel-gen/bin/dist/value-objects.js:39:47)
at /usr/local/lib/node_modules/remodel-gen/bin/dist/logged-sequence-utils.js:20:26
at /usr/local/lib/node_modules/remodel-gen/bin/dist/promise.js:74:12
at /usr/local/lib/node_modules/remodel-gen/bin/dist/promise.js:30:13

Currently, algebraic type matchers are implemented approximately like so:

switch (_subtype) {
  case _SomethingA:
    aMatchHandler();
  ...

This means that it's required to create and pass in empty blocks for every handler, because a match that tries to call nil as a function will cause a crash. It would be convenient for code that is aiming to only handle specific matches to not need the wordy implementation of empty blocks, and this could be achieved by if (aMatchHandler) { aMatchHandler(); }.

It seems impossible to generate a class with repeated function prefixes:

MyClass  {
  create:1 {
    NSString *username
  }
  create:2 {
    NSString *userId
  }
}

should be able to generate the code

@interface MyClass : NSObject <NSCopying>

+ (instancetype)createWithUsername:(NSString *)username;

+ (instancetype)createWithUserId:(NSString *)userId;

...
@end

but because in the .value file both have the same key create the generation fails with

Algebraic types cannot have two subtypes with the same name, but found two or more subtypes with the name create

Warning : Javascript noob (apologies in advance)

Trying to create a custom plugin but getting hung up on requiring various js files.

What I have done:

1. Installed via 'npm install -g remodel-gen'
2. Made custom plugin 'dictionary_plugin.ts'
3. Referenced the plugin in .valueObjectConfig as follows:

{
    "customPluginPaths": [
        "plugins/dictionary_plugin.ts"
    ]
}

1. Require via absolute path in dictionary_plugin.ts

var ValueObject = require('/usr/local/lib/node_modules/remodel-gen/bin/dist/value-object');

No errors occur when I gen (it finds the plugin properly and I refer to it in my .value object). However any time I access an attribute of ValueObject it crashes. Looking at the contents of value-object.js in particular was confusing as it only contains a single line

"use strict";

So theres a couple things odd to me that may stem from my lack knowledge on nodejs.

1. When installed via npm all dependencies i.e. value-object are .js files, however on this repo they are all .ts files (understand the difference in language, just unsure why the discrepency).
2. When trying to install directly from github using 'npm install -g https://github.com/facebook/remodel.git' none of the ts files get included

Ultimately, my question is what is the simplest way I can import/require all of the files required for creating the plugin from the npm installation inside of dictionary_plugin.ts. In general I am looking for objc.js, value-object.js, maybe.js, etc. Unable to figure out a straight forward way to do this. Thanks a ton for any help you can provide!

dictionary_plugin.ts path

 ProjectRoot/ValueModels/plugins/dictionary_plugin.ts

.valueObjectConfig path

 ProjectRoot/ValueModels/.valueObjectConfig

It'd be great to setup the functional and unit tests to run automatically on Travis CI.

I was wondering if there is an easy way to generate the model objects from a JSON response

Thanks

When I run remodel-gen,

/usr/local/lib/node_modules/remodel-gen/bin/dist/js/object-mona-parser/value-object/value-object-parser.js:32
    foundType: parsedType
               ^

ReferenceError: parsedType is not defined
    at Object.parse [as parseValueObject] (/usr/local/lib/node_modules/remodel-gen/bin/dist/js/object-mona-parser/value-object/value-object-parser.js:32:16)
    at Object.parse (/usr/local/lib/node_modules/remodel-gen/bin/dist/value-object-parser.js:72:35)
    at evaluateUnparsedValueObjectCreationRequest (/usr/local/lib/node_modules/remodel-gen/bin/dist/value-objects.js:31:41)
    at right (/usr/local/lib/node_modules/remodel-gen/bin/dist/either.js:46:39)
    at match (/usr/local/lib/node_modules/remodel-gen/bin/dist/either.js:34:16)
    at Object.mbind (/usr/local/lib/node_modules/remodel-gen/bin/dist/either.js:47:12)
    at parseValues (/usr/local/lib/node_modules/remodel-gen/bin/dist/value-objects.js:39:47)
    at /usr/local/lib/node_modules/remodel-gen/bin/dist/logged-sequence-utils.js:20:26
    at /usr/local/lib/node_modules/remodel-gen/bin/dist/promise.js:74:12
    at /usr/local/lib/node_modules/remodel-gen/bin/dist/promise.js:30:13

The remodel parser rejects the following valid type definition:

%type name=FIGColorType library=FIGColor file=FIGColor canForwardDeclare=false

# Attributes of FIG Buttons
FIGButtonAttributes {
}

With the following error message:

[error][Tue Jan 23 2018 10:08:14 GMT-0800 (PST)] [/Users/dthurn/path/to/code/FIGButtonAttributes.value] (line 3, column 1) expected string matching {{}
expected string matching {,}
expected space
Successfuly generated 0 objects. Encountered 1 errors in other files

It should allow comments to be placed after %type directives.

(also: 'successfully' is spelled wrong, which always slightly annoys me?)

Is there an example of using remodel with Swift?

Hi,

I am trying to add support (a new custom plugin) for alternative encoding format such as flatbuffer. There is a difficulty of supporting these encoding format, because they do not have switch cases in the decoding / encoding process. I am currently thinking of two possible solutions: 1) creating additional classes for each subtype, and then encode/decode an _adtObject (this will be casted to different subtype classes) instead; 2) simply encode/decode every declared properties.

Please let me know which approach will you recommend. Thanks!

Xcode 9.3 is not happy when you use %zd and %tu as a specifier for NSInteger and NSUInteger variables. They will generate warnings either when compiling on an iPhone 5c, or when compiling on an iPhone 5s+ (compile to Generic iOS device to test it):

Enum values with underlying type 'NSInteger' should not be used as format arguments; add an explicit cast to 'long' instead

This sucks if you have a project treating warnings as errors.

I suggest changing the implementation to the recommended Xcode fix-it solution: explicitly cast to (long) or (unsigned long) and use the %ld/%lu specifiers.

Do you guys have something similar for Android? I am wondering if one could keep a model repository that would generate code for both iOS and Android version of the app so one could keep consistency across.

I've not used Typescript much before (in fact, just installed it before using Remodel) and use NPM maybe twice a year, so I might be missing something entirely obvious. I've browsed the past issues and wasn't able to get things quite working.

I'm attempting to install the IGListDiffable plugin documented here. The hang up occurs when I try to build things.

I've cloned this repo locally, and for brevity it's installed at something like this:
desktop/test/remodel-master

With a clean clone, I'm not quite able to build it:
cd /path/to/remodel
./bin/build

I get this error (it seems it can't locate promise.ts which appears to be in the src folder):

/Users/Jordan/Desktop/Test/remodel-master/bin/build ; exit;
module.js:549
    throw err;
    ^

Error: Cannot find module 'promise'
    at Function.Module._resolveFilename (module.js:547:15)
    at Function.Module._load (module.js:474:25)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/Users/Jordan/Desktop/Test/remodel-master/bin/build.js:10:17)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]

More than happy to provide more details, and thanks releasing such a useful project!

Blocks are by default stack allocated, and as I understand it, there are cases where losing the type can cause ARC to retain rather than transfer ownership from stack to heap – and I think no automatic copy happens in MRR.

In the ARC case, the block could be retained rather than copied by the blocks runtime, in the MRR case, neither might happen. I think it would be safe to treat blocks as immutable types and copy them in initializers.

This is probably easier to explain as an example:

Foo.value

%library name=FooLib
Foo {
  %import library=BarLib file=Bar
  NSArray<Bar *> *bars
}

Generates:

#import <FBValueObject/FBValueObject.h>
#import <Foundation/Foundation.h>

@interface Foo : FBValueObject <NSCopying>

@property (nonatomic, readonly, copy) NSArray<Bar *> *bars;

- (instancetype)initWithBars:(NSArray<Bar *> *)bars;

@end

Notice that #import <BarLib/Bar.h> is missing, therefore causing it to fail to compile. Whereas if you do:

Foo2.value

%library name=FooLib
Foo {
  %import library=BarLib file=Bar
  Bar *singleBar
}

It generates the correct import:

#import <FBValueObject/FBValueObject.h>
#import <Foundation/Foundation.h>
#import <BarLib/Bar.h>

@interface Foo : FBValueObject <NSCopying>

@property (nonatomic, readonly, copy) Bar *singleBar;

- (instancetype)initWithSingleBar:(Bar *)singleBar;

@end

Seems to me we should just be importing everything that explicitly included via %import, but not sure whether that was an explicit product decision.