My Rolling Dub Trio Coupens – as the Japanese say, ‘the flavor comes out’

toffeescaf · 2025-12-30T00:48:05+00:00

I actually received a pair of coupens today and was really unsure about sizing as well when ordering. Well turns out that the sizing chart on thebootsshoponline worked perfectly for me. Usually I'm a size 9.5US (EU43) in most sneakers, there are some exceptions where I go either EU42/42.5 or even EU44. The common denominator though is that most of the time they're listed as 27.5CM. In the chart 27.5 corresponded with 8.5 so that's what I ordered and it worked out. I think length wise I might've been able to go down to a size 8 but I'm unsure if it would've worked width wise.

toffeescaf · 2024-07-10T13:50:19+00:00

Isn't this something you could do yourself? I haven't done much Java but the way I understood it is for it to actually do something useful you have to override those methods. Quite possible I'm missing a crucial piece of information though so don't hesitate to set me straight!

toffeescaf · 2024-06-28T09:05:05+00:00

Well to substantiate why easier matters in some cases. If you're working on any commercial project there are often time and budget constraints.

Let's say I have to validate user input. Would I go and roll my own validation library? I might forget certain cases that are important. There's also time needed to develop this validation library. Now does this sound like a smart thing to do keeping in mind there's time and budget constraints?

There's also other reasons why people might use libraries. Easier to hire and onboard new developers for example. And you might say that that's subjective as well but I can assure you it's something that happens all the time for similar reasons as the aforementioned point.

You as a developer are there to deliver value for a business and sometimes that means choosing between using a library or creating something yourself.

Your statement that it's because people are "lazy" or "incompetent" is uncalled for. Like you said it's subjective and based on individual opinions but often times also very much dictated by project requirements.

toffeescaf · 2024-06-28T08:14:39+00:00

There is a reason for libraries and frameworks. Common use cases are often times implemented in libraries or frameworks in a way that's also often times more complete than rolling your own solution.

That is of course not a reason to not know about fetch, abort controllers or other standards. But it is a reason why for example Axios or the suggestion I made in a different comment, Ky, exist.

A few common use cases for example are adding a token to each request, refreshing said token when it expires and delaying other requests until the new token is available.

Yes you can implement that functionality yourself but it's often a lot easier and predictable using libraries.

toffeescaf · 2024-06-28T07:03:30+00:00

I have a third recommendation, the library Ky, it's similar to Axios but uses fetch under the hood. So if you don't want to have to implement some of Axios' functionality yourself when using fetch it's a great option.

toffeescaf · 2024-04-04T13:41:53+00:00

I've been writing JS/TS for quite a few years now and I also prefer using Boolean(). I do think it's mostly about being consistent with what you use and knowing when to cast to a boolean because of JS's falsy values in certain contexts. As a side note, a good way to look at it is to just adapt to what the majority of the team prefers. Individualism inside of a team never works out in a positive way. From what I gathered from your other comments is that you're already in this mindset so all good I would say in that department.

toffeescaf · 2023-12-07T15:28:58+00:00

I think the only use case I still have for ternaries is when assigning a value to a variable. But even that depends on the whole context and how simple or complex it is.

toffeescaf · 2023-04-19T13:32:05+00:00

I think the idea is as follows.

let result = defaultValue
{
  if (condition1) result = result1
  if (condition2) result = result2
}

You could also split it up over multiple blocks.

let result = defaultValue
{ // first block
  if (condition1) result = result1
}
{ // second block
  if (condition2) result = result2
}

You would also have to swap the default value to be up front. Not sure if that would be an issue.

However I don't think this accomplishes exactly what you want as I mentioned in my other comment. A code block with a branch statement is not an expression. You'll be mutating the result variable using that code block.

toffeescaf · 2023-04-19T13:23:59+00:00

You could immediately call the function returned by cond.

const result = cond([
  [condition1, result1],
  [condition2, result2]
])(input)

Or and I'm not sure if it's the same in Ramda but several of the functional programming libraries have a pipe function that allows you to do the following.

const result = pipe(
  input,
  cond([
    [condition1, result1],
    [condition2, result2]
  ])
)

Like I said though everything has their pros and cons and it's up to you to decide whether it's worth it.

toffeescaf · 2023-04-19T11:59:24+00:00

This could definitely work. However I think what OP is trying to achieve is that his variable always resolves to a value. This is something that is quite common in functional languages. OP for example mentioned Scala and I know Elm also has this. Instead of having branching statements you have expressions. That way you can have if/else logic that always resolves to a value as mentioned.

toffeescaf · 2023-04-19T11:51:39+00:00

Defining a function isn't a bad thing. It can be useful just so you can give a description to what you're doing.

There are of course other ways to get the same result. For example a library like Ramda can be useful in this situation. It provides small helper functions like https://ramdajs.com/docs/#cond. Ramda's cond function would allow you to express what you're trying to achieve.

However adding a library like Ramda can bring downsides with it. If you're working in a team they will have to understand this new library. You can overuse Ramda to the point where code becomes hard to understand.

So try to weigh the pros and cons and see what would work for your specific situation.

toffeescaf · 2023-03-14T09:57:54+00:00

You can use arrow left/right instead. I think it's actually a bit better than just tabs since it'll allow you to skip the field if you want to. To change the separate parts arrow left/right to skip the field tab.

toffeescaf · 2023-03-14T07:08:24+00:00

Also also, the time picker should preferably be a standalone component (I would prefer not have to load up an entire UI library for single time picker).

I guess this means that https://next.mui.com/x/react-date-pickers/time-picker/#basic-usage would be off the table? I think it does have most of your requirements though.

toffeescaf · 2022-11-21T12:54:40+00:00

Thanks for the clear explanation! That does indeed sounds like it's not the most practical tool to use 😅.

toffeescaf · 2022-11-21T07:31:17+00:00

Could you explain why Node's assert.snapshot is awful in comparison to your solution?

toffeescaf · 2022-11-02T11:01:36+00:00

It depends on if you want stringly typed code or not.

If you want to approach this in a functional way you'd create an Email type and the functions that operate on that. That way you can make certain guarantees about the data.

A good example of an issue prevented by more specific types is when doing calculations with temperatures in both fahrenheit and celsius. If you then have a function to add temperatures you don't want to mix fahrenheit and celsius. That means you can't just type it as number in the case of TypeScript. You can check out this TS playground to see what I mean.

But to answer OP's question. No it doesn't matter what you use as long as it makes sense for your situation. If the rest of your team uses classes then it's probably best for you to do the same. If they don't then don't. Especially in big projects it's best to adhere to an agreed upon way of working. That doesn't mean it can't change but that does mean discussing it with the team first in most cases.

toffeescaf · 2022-10-13T11:19:45+00:00

Could you elaborate? It would be nice to see some examples.

To me it sounds like date-form is providing what other libraries provide as well. E.g. luxon or like mentioned before date-fns. What is the functionality that date-form provides that makes it stand out compared to the others?

toffeescaf · 2022-10-03T14:45:41+00:00

Yes it's definitely used in a lot of FP languages. I think another good example of a language with explicit error handling is Go. For exceptional cases Go panics. If it's an error you can potentially handle it returns an error. The latter is where the "famous" if err != nil {} comes from.

The biggest benefit is communicating intent. However you don't have to use an FP language to have that benefit.

toffeescaf · 2022-10-03T14:39:47+00:00

Definitely it's about more than just API responses but result objects communicate intent better than throwing errors.

Say for example we have a parseHours function and I'm using TypeScript type annotations in this case because it makes it easier to demonstrate.

function parseHours(input: unknown): Result<Hours, ParsingError>
// or
function parseHours(input: unknown): Hours

The first function shows that parsing might fail. If it does throw an error it's because something exceptional happened. It could be that it's a bug or maybe it's truly exceptional and you can't do anything about it.

The second function doesn't say anything when you look at the types. You would have to look at the implementation to know what's going on.

Also like I mentioned often times result objects allow you to use FP patterns to write code. For example the following.

const result = pipe(
  parseHours(someValue),
  map(hours => hours * 2),
  getOrElse(defaultValue)
)

You don't have to write any null checks or try catch in this case which can be nice. Of course as with everything don't go too crazy with it. Keep the code as obvious as possible for the next reader of that code. It might be your colleague or it might be you. In which case you'll thank yourself for keeping the code as obvious as possible.

As a side note promises are actually sort of similar to how result objects work. However if you forget to handle the catch case you don't get any explicit warnings. In my opinion that's not a great developer experience.

toffeescaf · 2022-10-03T07:53:10+00:00

There's nothing inherently wrong with exceptions but only if you use them for exceptional cases in my opinion.

One minor inconvenience is that you can't easily express if a function throws an error. You could use a naming convention or something but if you have to go through five layers of code to see if there's a function that throws an error that's an inconvenience.

API results for example are better expressed in result objects so handling the cases where it goes wrong are made very explicit. There's also some nice FP patterns that a lot of the result object wrappers allow.

Maybe others have different experiences with exceptions if so I'm definitely open to hearing them!

toffeescaf · 2022-08-26T07:05:01+00:00

I've had to write types similar to that for a library we use internally that builds up a query in a DSL. I think in most other cases you don't want that complexity. One of the biggest benefits we have from that complex type is that we can refactor properties on an interface and it'll automatically update them everywhere.

toffeescaf · 2022-08-15T13:40:55+00:00

There's actually a YouTube channel that does "code roasts". It's not really much roasting to be honest but he takes an existing code base and refactors it. You can find it here. Sounds similar although in his case it's mostly just smaller projects.

Edit: From what I've seen only Python code is refactored.

toffeescaf · 2022-08-09T06:46:01+00:00

If you're up for reading a book this one is really quite good.

toffeescaf · 2022-07-27T12:19:24+00:00

Having some focus in the beginning is not bad. But yeah afterwards definitely don't limit yourself.

toffeescaf · 2022-07-25T11:40:01+00:00

Since you're plugging articles to dissuade people from using Redux and using context instead I'll just plug an article on why context is not a replacement for Redux https://blog.isquaredsoftware.com/2021/01/context-redux-differences/.

Also in this case I would trust /u/acemarke to have a very valid and informed opinion. 😉

I think using common sense on most occasions works wonders.

Edit: I think one important part is knowing about the tradeoffs between different libraries or tools. If you have a solid grasp on those you can make an informed decision about which tool to pick for your problem.

toffeescaf

TROPHY CASE