https://htmx.org logo
Powered by
# htmx-general
  • g
    i am a javascript :microwave-brain:
  • m
    \> just smile and pretend u know what a reducer is
  • m
    😃
  • g
    it's the first argument of 
    reduce()
  • m
    😃
  • g
    finalState = events.reduce(reducer, initialState)
  • m
    😃
  • p
    There's a reductive argument going on in JS twitter right now
  • p
    That said whenever @User posts something about HATEOS I think he's promoting some edgy Linux distro
  • m
    i actually registered hateoas.org so I don't have much of an excuse
  • g
    people always ask about reusing the same endpoints for web (HTML) and native (json?) apps, so I'd like to ask, what does this channel think about microformats? https://developer.mozilla.org/en-US/docs/Web/HTML/microformats here's an example of an app that uses it for an HTML-based API: https://brid.gy/about#api
  • m
    my experience is that your data end points are best separated from your web app end points
  • m
    html seems like a bad data format, as JSON seems like a bad hypermedia, to my eyes
  • m
    maybe for client scripting tho?
  • g
    as this blogpost argues, that can lead to inconsistency between the two. with an html api, you can't break your open api without breaking your own website.
  • m
    yes, that's a trade off
  • m
    It Depends(tm)
  • g
    html isn't the most compact data format to be sure, but microformats seem expressive enough, and the api consumer never interacts with the actual document structure so you don't have the usual concerns about redesigns
  • m
    does changing your web app change your data api?
  • g
    if all else fails you can stuff a bunch of hidden elements in there
  • g
    depends how much you change it, I suppose
  • m
    seems like the more regular and simple your app is, the more that this approach would work
  • g
    i'd argue if you add a feature to your web app you should add it to your api (cough twitter polls)
  • m
    my experience is that it is better to separate the data API
  • m
    ah, that makes sense
  • m
    web automation
  • m
    that I can see
  • g
    you could maybe make non-user-visible endpoints for api-specific stuff
  • g
    yeah, that's the bridgy use-case
  • b
    is there a repo i might be able to check of yours?
1...273274275...1146Latest