First draft of elm encoder backend #9
Conversation
| typeDefToEncoder : extra -> Name -> AccessControlled (Definition extra) -> Declaration | ||
| typeDefToEncoder e typeName typeDef = |
There was a problem hiding this comment.
If you just want to ignore the extra type argument you can remove the first argument. Type variables in function signatures are defined the first time they are used.
There was a problem hiding this comment.
I guess I could have removed it but I decided to keep it just in case I need to put something in the Node range a of my output.
|
|
||
| functionName : String | ||
| functionName = | ||
| toCamelCase <| [ "encode" ] ++ typeName |
There was a problem hiding this comment.
It's stylistic but I would do [ "encode" ] ++ typeName |> Name.toCamelCase. I also like to prefix functions that are not defined in this module. Makes things easier to follow.
There was a problem hiding this comment.
I agree. I noticed the same while I was reading the PR.
| const packageDefWorker = require('./Morphir.Elm.CLI').Elm.Morphir.Elm.CLI.init() | ||
| const elmEncoderWorker = require('./Morphir.Elm.EncodersCLI').Elm.Morphir.Elm.EncodersCLI.init() |
There was a problem hiding this comment.
Longer term I think we should just have one worker and use it as a facade to consolidate all the functionality but I'm guessing this was meant to be a temporary solution anyway so OK for now.
There was a problem hiding this comment.
That is a good suggestion. I did think of that but like you said, for the purposes of getting something out quicker I fell short of consolidating it.
| @@ -4,7 +4,7 @@ | |||
| "description": "Elm bindings for Morphir", | |||
| "scripts": { | |||
| "test": "elm-test", | |||
| "make-cli": "cd cli && elm make src/Morphir/Elm/CLI.elm --output Morphir.Elm.CLI.js --optimize" | |||
| "make-cli": "cd cli && elm make src/Morphir/Elm/CLI.elm --output Morphir.Elm.CLI.js --optimize && elm make src/Morphir/Elm/EncodersCLI.elm --output Morphir.Elm.EncodersCLI.js --optimize" | |||
There was a problem hiding this comment.
We should use a better build tool such as Gulp. Created issue for it: #10
There was a problem hiding this comment.
I have no experience with JS build tools. Would be fun to know what's out there since I have always been intrigued by the choices available in the JS ecosystem.
| case tpe of | ||
| Reference fqName typeArgs _ -> | ||
| case fqName of | ||
| FQName _ _ [ "int" ] -> |
There was a problem hiding this comment.
This is the kind of stuff that we should put into the SDK as a reusable pattern. It would be too much to do now but can you please add a TODO comment?
There was a problem hiding this comment.
You mean these should be parsed as data-structures represented in the SDK, right?
There was a problem hiding this comment.
First, it should be added as a pattern in the SDL. This would be SDK.intPattern. But this is longer term.
…ot chain the names in the object
|
|
||
| functionName : String | ||
| functionName = | ||
| [ "encode" ] ++ typeName |> toCamelCase |
There was a problem hiding this comment.
Can you do Name.toCamelCase as discussed?
Added Scala Library dependency
WIP