The Web Design & Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

«‹›360 »

Leshy: Jun 21, 2004

The Merkinman posted:

If you set the height to something smaller, so that the list doesn't fit in one column --height: 400px ... it does weird stuff.

With the current lists in the CodePen, it looks as expected down until about a minimum height of 260px, where the number of columns starts exceeding the width of the container. Changing the explicit width on the lists to flex: 0 1 166.67px will alleviate it a little bit by allowing the lists to shrink as needed, but again you will hit a lower limit at some point.

In the end, the lists are individual items that will not break into multiple columns, and when you have more lists or longer lists than the container can handle, you will have issues. If you also want the individual list items to wrap into new columns, you would have to put all list entries and headers into a single list � that would allow flexbox to automatically wrap them correctly, but you would lose the individual list semantics. This is pretty similar to what your suggested JS-based solution would do, by evaluating each individual list item and placing it manually.

This exercise shows why fixed sizes are generally not recommended in webdesign, especially when dealing with variable content. The moment you end up with an unexpected amount of content, things will break in one way or another and you're going to have to set up a bunch of contingencies to deal with those. Having said that, I do not know what your specific use case is here.

# ? Feb 12, 2024 21:45

Adbot: ADBOT LOVES YOU

# ? Apr 16, 2024 05:19

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Leshy posted:

With the current lists in the CodePen, it looks as expected down until about a minimum height of 260px, where the number of columns starts exceeding the width of the container. Changing the explicit width on the lists to flex: 0 1 166.67px will alleviate it a little bit by allowing the lists to shrink as needed, but again you will hit a lower limit at some point.

In the end, the lists are individual items that will not break into multiple columns, and when you have more lists or longer lists than the container can handle, you will have issues. If you also want the individual list items to wrap into new columns, you would have to put all list entries and headers into a single list � that would allow flexbox to automatically wrap them correctly, but you would lose the individual list semantics. This is pretty similar to what your suggested JS-based solution would do, by evaluating each individual list item and placing it manually.

This exercise shows why fixed sizes are generally not recommended in webdesign, especially when dealing with variable content. The moment you end up with an unexpected amount of content, things will break in one way or another and you're going to have to set up a bunch of contingencies to deal with those. Having said that, I do not know what your specific use case is here.

Oh wow. I just noticed something which would explain some of my confusion. Looks like that works in Chrome, but not Firefox (what I was doing dev in) nor Safari.
In the latter two, while it does flow onto multiple columns, the width of #lists stays the width of only one column.

# ? Feb 12, 2024 22:34

Leshy: Jun 21, 2004

Ah, you're right. On Firefox (and presumably Safari) the auto setting on the Grid container does not play nice with the actual width of the flexbox it contains.

Setting it to fit-content should work: https://codepen.io/LeshyNL/pen/BabqMKr

# ? Feb 13, 2024 22:56

Ihmemies: Oct 6, 2012

We implemented a billing system as a server side rendered single page app, with typescript, tailwind, node.js, handlebars, htmx and postgres.

Oh boy this sucks. Pg plugin to node.js just ditches the type information, and nothing actually cares about the types during runtime. So we found out our numbers in interfaces are actually strings after a database query etc.

My blood pressure can't take more of that. I want to try a different style of footgun - would SeaORM and some rust framework like Actix or Rocket work for web development, as an actually typesafe alternative? :v:

I really can't deal with these scripting languages anymore.

https://github.com/SeaQL/sea-orm
https://keats.github.io/tera/docs/
https://actix.rs

Ihmemies fucked around with this message at 08:07 on Mar 25, 2024

# ? Mar 25, 2024 08:01

MrMoo: Sep 14, 2000

Drizzle ORM is the main one that comes up in search results, although it�s a bit tedious that yet again another layer wants to be the single source of truth for domain models.

https://orm.drizzle.team/docs/zod

# ? Mar 25, 2024 14:58

prom candy: Dec 16, 2005; Only I may dance

You're basically not gonna get database-to-client typesafety without using an ORM or query builder that wants to define your schema. Drizzle is very cool. Similarly there's Jet for Golang, but I haven't used that.

# ? Mar 25, 2024 18:49

abraham linksys: Sep 6, 2010

if you just want runtime type-safety with no ORM, you can hand-write zod schemas for the expected query results, and this brings up typescript to parity with, like, every other typed language where the types exist at runtime. there's some libraries that'll integrate this like slonik (https://github.com/gajus/slonik).

MrMoo posted:

Drizzle ORM is the main one that comes up in search results, although it�s a bit tedious that yet again another layer wants to be the single source of truth for domain models.

https://orm.drizzle.team/docs/zod

if you're using an ORM like drizzle you probably don't need any extra runtime validation? it already has its own schema DSL that i assume would enforce stuff at runtime

if you want actual end-to-end type safety when interacting with a database that is a huge can of worms in any language and can be a pit of a pain in the rear end to get set up (e.g. my java-heavy employer eventually gave up on JOOQ's DSL for being way too hard to work with and is still keeping on with JDBI). stuff like prisma exists but whoof that is some heavyweight stuff

abraham linksys fucked around with this message at 19:07 on Mar 25, 2024

# ? Mar 25, 2024 19:04

Sab669: Sep 24, 2009

Is there a better place to ask Dumb Angular Questions?

I have some function which uploads a file to my .NET API and either refreshes the page if the file is valid, or presents a list of errors if the file is invalid. For the latter, the C# code is just a simple:

return StatusCode(500, listOfErrors<T>);

My Angular function is basically just:

code:

foo(){
  this.uploadService.upload(file).subscribe(
  next: success => {
    //refresh the page
  },
  error: err => {
    //present the list of errors
  }
  ;)
}

upload(file: Blob): Observable<string>
{
  //creatiion of some objects
  return this.http.post<string>(apiUrl, formData, HeaderObject).pipe(catchError(this.handleError<string>('File Upload')));
}

But despite the API returning a 500 error, the code still steps into the "next" block. I feel like I've gotta be missing something absolutely stupid but I cannot seem to figure it out today :sigh:

Any ideas?

Sab669 fucked around with this message at 21:10 on Mar 25, 2024

# ? Mar 25, 2024 21:01

prom candy: Dec 16, 2005; Only I may dance

abraham linksys posted:

if you just want runtime type-safety with no ORM, you can hand-write zod schemas for the expected query results, and this brings up typescript to parity with, like, every other typed language where the types exist at runtime. there's some libraries that'll integrate this like slonik (https://github.com/gajus/slonik).

if you're using an ORM like drizzle you probably don't need any extra runtime validation? it already has its own schema DSL that i assume would enforce stuff at runtime

if you want actual end-to-end type safety when interacting with a database that is a huge can of worms in any language and can be a pit of a pain in the rear end to get set up (e.g. my java-heavy employer eventually gave up on JOOQ's DSL for being way too hard to work with and is still keeping on with JDBI). stuff like prisma exists but whoof that is some heavyweight stuff

adding runtime costs with something like zod is only really worthwhile if data is coming from sources outside your control imo. what you consider "outside your control" is entirely subjective though, i.e. i use zod to parse response shape for APIs that i control

# ? Mar 25, 2024 21:03

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

Sab669 posted:

Is there a better place to ask Dumb Angular Questions?

I have some function which uploads a file to my .NET API and either refreshes the page if the file is valid, or presents a list of errors if the file is invalid. For the latter, the C# code is just a simple:

return StatusCode(500, listOfErrors);

My Angular function is basically just:
code:
foo(){
  this.uploadService.upload(file).subscribe(
  next: success => {
    //refresh the page
  },
  error: err => {
    //present the list of errors
  }
  ;)
}

upload(file: Blob): Observable<string>
{
  //creatiion of some objects
  return this.http.post<string>(apiUrl, formData, HeaderObject).pipe(catchError(this.handleError<string>('File Upload')));
}
But despite the API returning a 500 error, the code still steps into the "next" block. I feel like I've gotta be missing something absolutely stupid but I cannot seem to figure it out today Any ideas?

i don't know angular at all, but my guess would be either catchError or this.handleError is swallowing the exception and instead returning a value that doesn't trigger the error block to run

# ? Mar 25, 2024 21:10

Sab669: Sep 24, 2009

Ugh, yea, honestly this place seems to decorate drat near all of their functions with that so tbh I thought it was just boilerplate Angular stuff (I still consider myself quite new to it) but digging into it, clearly not - if I just delete that whole .pipe(...) now it works exactly as it should :downs:

Thanks lol.

# ? Mar 25, 2024 21:16

SirViver: Oct 22, 2008

Sab669 posted:

...

Just a sidenote, I think a 400 Bad Request status code would be more appropriate for input validation errors than a 500 Internal Server Error.

Personally I'd only let the API's global unhandled exception handler return a 500. Any error condition you actively check for as part of your business rules should use whatever HTTP status code is most befitting of the situation - which is most likely one of the 400-range, like the ever elusive 418 I'm a teapot. But joking aside, realistically it's most likely a 400, 403, or 404.

Of course, technically it doesn't make a difference, as long as it's a status code that gets correctly interpreted as an error code by your HTTP client.

# ? Mar 25, 2024 23:18

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

422 might also be correct keeping in mind that nobody cares about any status code. As opposed to 400 Bad Request, 422 Unpossessable Entity says that while the request was interpreted and understood the server still isn't going to process the request due to something about the content of the request. Like yeah you gave me a cat name, but the cat name was too short so try again.

I guess 400 Bad Request is more like the whole request is fubar. But I've definitely seen it used more.

# ? Mar 26, 2024 00:10

Sab669: Sep 24, 2009

Yea you're probably right that 500 doesn't make the most sense. Was very much just a, "Copying the way these other endpoints do it" internally consistent jobs.

# ? Mar 26, 2024 00:59

FISHMANPET: Mar 3, 2007; Sweet 'N Sour
Can't
Melt
Steel Beams

The specific codes don't matter, but a good rule of thumb is "4xx is the user's fault, 5xx is the server's fault" lots of tooling will operate on those assumptions.

# ? Mar 26, 2024 01:08

prom candy: Dec 16, 2005; Only I may dance

The codes do matter and I think we should argue about them. 422 for invalid input, fight me.

# ? Mar 26, 2024 06:28

FISHMANPET: Mar 3, 2007; Sweet 'N Sour
Can't
Melt
Steel Beams

I'M A TEAPOT

# ? Mar 26, 2024 15:26

Adbot: ADBOT LOVES YOU

# ? Apr 16, 2024 05:19

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

Is there a way I can tell vite, when it's in serving mode, to not mess around with loose CSS files? I have two of them with basic formatting instructions for Paged.js.

In dev mode everything works fine, because they're in the public dir marked folder. When I build everything, the file layout also looks as its supposed to be. But when I want to test said output by using vite serve, while it serves the CSS correctly, if it's the first thing I attempt to load in the browser (by addressing it directly from the address bar), as soon as the app runs, vite starts serving it wrapped in some Javascript HMR boilerplate stuff from what it looks like. So Paged.js kind of ignores it with what not being CSS anymore.

I will eventually attempt to see what happens if I override the @page attribute on the DOM node, but the feeding a CSS file to Paged.js has so far worked smoother, because I've had already to do enough horrible things for in-place rendering of print previews in this SPA.

# ? Mar 28, 2024 19:39

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

«‹›360 »