Serializing model ids as numbers

Ember Data
1

I’m in the process of hooking Ember Data up to an API that uses numbers for IDs. Payloads from the API are deserialized without a problem, but unfortunately when models are sent to the API all ids are serialized as strings.

I understand this is because the store treats all ids as strings internally, but is there any easy way to convert them back to numbers during serialization?

As I need model ids (when included), relationship ids (i.e. belongsTo and hasMany) and the ids within embedded models to all be numbers the only way I can see to do this is to override DS.RESTSerializer’s serialize method - this works, but having to reimplement all the serialization logic seems a bit unnecessary.

Am I missing an easier solution? Any suggestions?

1 Like
2

FWIW it looks like there used to be a serializeId method that did pretty much what i’m after but it was removed in this commit: Remove leftover serializer code · emberjs/data@1c55815 · GitHub.

1 Like
3

What is the current solution for this issue? How do you handle it?

4

This is really why i started hating emberjs so badly after I was a big advocate for it… it’s badly maintained, and nothing makes sense anymore. and it’s buggy as hell.

Now need to find a way to rewrite a full year project with over 1k files into vuejs or react or anything else…

5

Can you share what’s badly maintained and what doesn’t make sense? Would love to fix all those issues.

Fwiw, I’ve done this before, and it’s not worth it. If you can upgrade to ember octane, or even the last LTS, 3.12, you’ll have a much better time.

I did react professionally for a long time. There are no abstractions and you have to build a framework yourself. Which… Only after 3 years, did I feel like I could do without totally falling flat on my face. You have to reinvent so many things.

3 Likes
6

Thanks for your reply, well the issues are so many to count tbh. but let’s take these as an example:

  1. The directory structure is not productive for large projects.
  2. Not enough UI libraries to back it up, I mean there is only Semantics and Ember Paper which both suck and are as badly maintained as well!
  3. Can you imagine how many times I had to reinvent the wheel, I mean rebuilding a component from scratch (a component that’s basically in all other frameworks).
  4. Can you imagine how many times I had to hack around some Ember addon or library to fix a bug in it. (and still facing so many bugs).
  5. I am using the latest ember version, but it has no 3rd party libraries to back it up.
  6. Not much improvement in the last 2+ years I’ve been using it.

Honestly, I know how hard it is to rewrite everything. And I’m fighting the temptation of doing it… But so far it looks like dragging a dead body… Not getting anywhere. My only hope now is probably finding some ember addon that allows to write Vuejs components for ember… and slowly using it to migrate from ember to vue.

7

Thanks for providing feedback! I have some thoughts on each of your bullet points, and maybe you’ll be surprised? Idk.

Yes, the default layout is bad. There is work going in to fixing it, but that doesn’t help you now. Today, what you can do is use ‘pods’ and/or component co-location. Here is my side project, using pods (technically hybrid pods and classic): https://github.com/NullVoxPopuli/emberclear/tree/master/packages/frontend Pods, along with componet co-location allow the js and hbs to live next to each other. Pods also allow the route/controller/template combo to live next to each other as well.

Not really sure what you’re looking for. Because there are all these: Ember Observer

  • semantic-ui-ember
  • ember-paper (As you mentioned, but also: )
  • ember-uikit
  • ember-element-ui
  • ember-material-lite
  • ember-bootstrap
  • and more!

And, fwiw, many companies roll their own, with custom styles using more generic componet add-ons, like,

  • ember-dropdown
  • ember-modal
  • ember-table
  • ember-tooltips
  • and more!

I guess, if there are specifics you can think of, we can try to find where those gaps one and fill them?

Sure can! Some company work I’ve done is a little bit of this. Knowing where to steal code from is important, but also trying to see if any of the generic add-ons will help you get there faster is good. This could also be a perspective? The above linked project, uses shoelace-css, which doesn’t have an ember addon, because I’m too opionated about how I want my components to be built and how I want them to operate.

Sure can! I try to encourage people to submit PRs to these add-ons or libraries. Cause odds are if you found a bug, others have, too. You say you’re still facing a ton of bugs, can you share what all you’re experiencing? Also, are you in the ember discord? A lot of times, the add-on devs hang out in there. emberjs

What do you mean by this? Specifically no 3rd party libraries to back it up? If you’re talking about using 3rd party libraries, there is ember-auto-import, which let’s you import anything naturally as you would in any other Js Ecosystem (via webpack, but you don’t configure anything)

Have you used ember Octane? Take a browse through emberclear ( the above linked project), and lemme know what you think. It’s all native JS now. (Though I’m using TS, but that’s easily stripped away, and ember’s primary focus is on the js experience)

Honestly, octane is such a breath of fresh air, it makes rewriting in another framework seem much much less worth your time.

If you have questions about octane, feel free to ask here, or in the octane discord channels :slight_smile:

1 Like
8

Thank you for your reply, appreciate it :slight_smile:

We do that already… and it’s not good enough rather it makes things worse having both layouts mixed within one massive project sucks.

If you have checked those, are all badly maintained or were not updated in long time, plus they lack any “decent” documentation or up to date UI/UX.

Sadly, with all that Octane brought to the table seems “not enough”, and “too late”… That’s how I see it.