davegurnell / bridges Goto Github PK

Have you considered allowing for customization of the ADT's generated type?

It seems currently (at least for the Typescript implementation), that ADTs end up with a hard-coded { type: <constructor name> }.

I would like to be able to:

• customize the field name for what is currently hard-coded to "type"
• supply a custom means for the ultimate value of the type field. Perhaps a function from (constructorName, typeName) => string.

If you think this is useful, I can take a stab at pull request. (I assume these options could be easily added to TsEncoderConfig?)

Readme may be out of date after we merge pending PR, review and update

Hi,
we've had an issue when using the lib with scala 2.12.6 because scala-library 2.12.1 is on the classpath too.

The error we got was:

java.lang.NoSuchMethodError: scala.util.Properties$.coloredOutputEnabled()Z

I don't know whether that is really "our problem" though.

We can represent these with a Ref. However, we can't predict from the type name what the JSON decoder/encoder code is going to look like in Elm, e.g.:

Uuid.decode

versus

decodeString

We need a way of looking up JSON decoder names by type. By default we look up a decoder with the same format of name that we render. However, the user can override this on a type-by-type basis.

It also makes sense to make the JSON encoder/decoder code specific to Elm for now.

The encoding of discriminated unions in Flow is complex and tends to produce byzantine type error messages. It might be worth having a dedicated DiscriminatedUnion type with a better encoding, or maybe we can detect this pattern in the renderer and do a better job.

We need to support them, I guess!

Some indentation and newlines might be nice...

Technically these two types are different: ?A means A | null | undefined. However, it's far more idiomatic to use ?A in Flow and I often have to code around A | null to get things to compile.

When a type contains a list of values, the generated encoder for Elm is wrong.
The reason is that the type of Encode.list is

Encode.list: (a -> Value) -> List a -> Value

but it is used with an encoder myEncoder: a -> Value in the following construct

Encode.list (List.map myEncoder listOfA)

which is a type error.

Reconstruction

import bridges.core.syntax._
import bridges.elm.Elm

object Issue {

  case class Child(
      number: Int
  )

  case class Parent(
      children: List[Child]
  )

  def main(args: Array[String]): Unit = {
    val (_, content) = Elm.buildFile(
      module = "TestModule",
      decls = List(
        decl[Child],
        decl[Parent]
      ),
      customTypeReplacements = Map.empty
    )
    println(content)
  }

}

The List.map needs to be removed entirely, which fixes the issue.

I'd like to bump the scala version for this project 2.13

I am waiting for the uident scala 2.13 update to be accepted davegurnell/unindent#3

I am creating this issue hopeing this will reach @davegurnell

I'd love to be able to generate json schema files

Ideally, it would support:

• sealed trait families map to oneOf
  • case object would be values, like in sealed trait T; case object A extends T; case object B extends T would be "type A, values oneOf A, B"
• AnyVal wrapper classes map to a named type, use sites would use $ref
• Schemas generated could reference each other, mirroring the scala file layouts/imports

Can we support Refined without requiring users to write additional code? e.g.

implicit def refinedEncoder[A, B](...): Encoder[A Refined B] =
  ???

There's no need to abstract over target languages for:

• JsonDecoder
• JsonEncoder
• FileBuilder
• Renderer

Just have, e.g., Elm.render(decls).

We might have a trait in core that specifies
a bar minimum set of methods that each language should implement
(i.e. render()), but we don't need implicit parameters
or shared syntax for these.

Bridges currently infinite loops if you try to compile a type for a self-recursive data structure. For example:

case class OneAnd(head: Int, tail: Option[OneAnd])

I'm not sure why this happens. We shouldn't be recursing more than one layer deep into a struct definition. However, we clearly are!

I have a hunch the definition of Intersection is over-complicated. I need to review this with @pvillega.

Version 0.18 added TsType.Tuple and FlowType.Tuple to encode tuple Typescript and Flow tuple types:

export type SpreadsheetCell = [string, number];

We can currently create these types using the DSL:

decl("SpreadsheetCell")(tuple(Str, Intr))

However, we can't yet map Scala tuples onto them using decl[T]. If we can add tuple support to Elm's model, we can write some scala.TupleX encoders using shapeless of sbt-boilerplate.

A Scala type satisfying the properties:

1. All fields are optional
2. The generated Elm file is in its own file

yields an incorrect Elm file, because an import is missing.

Reconstruction

import bridges.core.syntax._
import bridges.elm.Elm

object Issue {

  case class OptionOnly(
      number: Option[Int]
  )

  def main(args: Array[String]): Unit = {
    val (_, content) = Elm.buildFile(
      module = "TestModule",
      decls = List(
        decl[OptionOnly]
      ),
      customTypeReplacements = Map.empty
    )
    println(content)
  }

}

The distinction, whether or not the decoders contain required needs to be removed in ElmFileBuilder.scala.