vt-elixir/ja_serializer

support for phoenix 1.3

mikeni opened this issue · 27 comments

are there any plans for Phoenix 1.3?

some things have been moved around such as
Mix.Phoenix.attrs/1 has been moved to Mix.Phoenix.Schema.attrs/1

@mikeni I am not currently using this project in any Phoenix 1.3 apps, but PRs are very welcome!

how should the naming for mix generate task work? in phoenix 1.3, model is replaced by context and schema

in addition to the current generator,
mix ja_serializer.gen.phoenix_api User users name:string age:integer

should we add something like
mix ja_serializer.gen.phoenix_api_v13 Accounts User users name:string age:integer

?

created a Pull Request for this

#243

What's the hold up on this PR?

You could technically add this to your mix file

https://github.com/mikeni/ja_serializer/tree/phoenix-1-3-generator

it will get you 80% there,

There are some underlying issues due to context and schema.

If you have an association that goes outside of your context, there isn't enough information to get the proper module namespace.

I did fix some stuff using the correct underscore vs dasherize based on configuration. It was always using underscore before.

I plan to write a library that can generate files for phoenix 1.3 with and without the following:
ja_serializer vs default
fixture vs ex_machina

also something that can also generate proper migration files as well as changesets

tired of manually doing it

@cottrellio @mikeni I have been waiting to hear 1.3 is released. I don't use generators so I am just going to take it on faith this works and merge when I see more then a RC has been released.

I'm actually new to Elixir/ Phoenix so I thought having a generator would make it easier, but honestly just using the 1.3 json generator and then following the ja_serializer readme to install and use it is pretty straight forward. I guess all I'm saying is I didn't mean to put so much pressure on this PR.

I'm not too concerned with the generators, but I can't seem to figure how to get it to use the MyAppWeb namespace instead of the MyApp namespace

will this PR get mix ja_serializer.gen.phoenix_api fixed @mikeni ?

@greyhwndz I made a new generator
mix ja_serializer.gen.phx_api Posts Comment comments name:string age:integer user_id:references:users

to be in the same style as the new phoenix 1.3 generators, with the context and schema instead of model

@mikeni - trying this out now... any ideas?

mix ja_serializer.gen.phx_api Posts Comment comments name:string age:integer user_id:references:users

** (UndefinedFunctionError) function Mix.Phoenix.copy_from/5 is undefined or private. Did you mean one of:

@mikeni - this fixed what I was seeing.. would love to get a release for this (though I agree w/ trying to separate phoenix concerns down the line)

Though @mikeni there are a handful of warnings at startup:

warning: String.strip/1 is deprecated, use String.trim/1
  lib/ja_serializer/content_type_negotiation.ex:46

warning: variable "raise_with_help" does not exist and is being expanded to "raise_with_help()", please use parentheses to remove the ambiguity or change the variable name
  lib/mix/tasks/ja_serializer.gen.phoenix_api.ex:108

warning: variable "raise_with_help" does not exist and is being expanded to "raise_with_help()", please use parentheses to remove the ambiguity or change the variable name
  lib/mix/tasks/ja_serializer.gen.phoenix_api.ex:117

warning: variable "test_prefix" is unused
  lib/mix/tasks/ja_serializer.gen.phx_api.ex:50

warning: variable "web_path" is unused
  lib/mix/tasks/ja_serializer.gen.phx_api.ex:51

warning: function Mix.Phoenix.attrs/1 is undefined or private
  lib/mix/tasks/ja_serializer.gen.phoenix_api.ex:36

warning: function Mix.Phoenix.params/1 is undefined or private
  lib/mix/tasks/ja_serializer.gen.phoenix_api.ex:44

warning: function Mix.Phoenix.copy_from/5 is undefined or private. Did you mean one of:

      * copy_from/4

Found at 2 locations:
  lib/mix/tasks/ja_serializer.gen.phoenix_api.ex:57
  lib/mix/tasks/ja_serializer.gen.phoenix_api.ex:60

Hmm, that is the generator for phoenix 1.2, I suppose it doesn't work now. Both 1.2 "ja_serializer.gen.phoenix_api" and 1.3 "ja_serializer.gen.phx_api" generators were working in the earlier release candidates. I suppose only 1.3 works now. Should we delete the old generator? or rename the new one, "ja_serializer.gen.phx_api" to the old name, "ja_serializer.gen.phoenix_api"?

^ This is exactly the reason I want to move phoenix support out of this repo. Nothing about the serializers themselves has changed at all with the new phoenix release.

Unfortunately I don't have the availability to undertake this currently, but I would fully support and endorse any effort to do so.

I think the steps would be:

  1. Copy PhoenixView and install documentation over.
  2. Optional - Copy old generators over.
  3. Optional - Release a 0.1 version with phoenix 1.2 support.
  4. Copy new generators over, remove old generators.
  5. Release 1.3 support version.
  6. Drop all code from main repo, update docs, add link to new repo.
  7. Prepare for a 1.0 release that breaks compatibility and removes all deprecated APIs. (I have one other item to get in for 1.0 - a plugable adapter)

We could potentially skip 2 & 3 in favor of adding manual install instructions (which I will probably do anyway, there is so little phoenix specific code).

@alanpeabody - for what it's worth - I was mostly interested in the generators to see what the "suggested structure" would look like. Now that I've started setting things up, I'm more in @cottrellio's boat around just using the normal phoenix generators. It feels out of scope for this repo to care so much :) So basically, I agree w/ your steps above, but I personally wouldn't use that new repo for generation.

Yeah, and even the JaSerializers.PhoenixView feels like it would be better handled manually - to ensure users have a full understanding of exactly what JaSerializers does and what Phoenix does. It is really only like 4 lines of glue code.

@alanpeabody I did as you suggested, created a library for generators
https://github.com/mikeni/phoenix_custom_generators
there is a link in the README for pre phoenix 1.3 support
it allows you to optionally use ja_serializer as well as ex_machina

if you are ok with it, we can remove the generators from ja_serializer

I am currently trying Phoenix 1.4.
Can I do the following in the config/config.exs to use Jason for ja_serializer?

config :phoenix, :format_encoders, "json-api": Jason

instead of

config :phoenix, :format_encoders, "json-api": Poison

@greyhwndz yes, that's exactly what I use.

@beerlington why does it take several months to make a release instead of an incremental one? it's been more than a year since the last release (0.13.0). Just askin' :)

I think the answer is largely https://github.com/absinthe-graphql/absinthe 😁 We moved away from this form of serialization when we discovered we were the only ones left using it.

I was planning to go into absinthe but not for the moment. That is why I tried to get back into json-api thru ja_serializer. Does AbsintheGraphQL really cover all the things that json-api does? And are you saying nobody except me (perhaps) is using Absinthe-GraphQL?

I was mostly kidding and this isn’t the proper place for such talks. That said - I’ll leave you with this -

They are 100% different - gql solves nearly every problem I’ve faced w/ complex api design over my career- and yes it introduces a few complex issues that standard rest solved nicely. On top of that, Absinthe is easily the most impressive set of tools we use; we are a big fan.- To be clear we also use this library for our legacy endpoints, I just think when you find yourself wondering why a release takes a year, it’s often times because you are betting on the wrong horse.

I'm using this in production in a Phoenix 1.4 app and haven't run into any issues. Closing this issue since it seems like most of the outstanding 1.4 related things are for the generators and have separate issues open. If there's anything else related to 1.4, please open another PR.