Make humanTime utility function extendable

LuoTR

The date formatting issue caused by humanTime was actually discussed many times before.

By now it's still an unresolved issue in core. I would like to propose to make it extendable by extensions so that its behavior can be easily changed without modifying core. This is kinda of like a workaround, but it works isn't it?

I'd like to hear some feedbacks from the core development team about this, and if accepted then I can work on this.

LuoTR

I've just come up with an idea to make humanTime extendable.

Create a class called Utility
Create a static function called humanTime in class, which is the original humanTime
(For backward compatibility) Make the original humanTime a wrapper that calls the humanTime in Utility

In this way if an extension wants to extend humanTime, it can use extend with Utility to accomplish it.

Edit:

One thing to mention.

In this approach, to use the humanTime, the caller should only keep the reference to Utility class, not Utility.humanTime. Otherwise, the extenders and overriders won't work.

Eric_Lian

considering refactoring it to a component?

LuoTR

Eric_Lian Why is that? I don't think this should be taken care of by mithril.
From how extend and override is implemented, it doesn't need to be a component to work if I understand it correctly.

askvortsov

@SychO the export registry changes didn't involve having relative exports resolve to the registry at runtime, right?

SychO

askvortsov no it did not involve that aspect.

LuoTR

If possible, we can move all utility functions into Utility class, which greatly improves the extensibility of core.

Also, the original functions can be directly deprecated in 2.0 by making breaking changes, reduces unnecessary backward compatibility functions at the same time.

LuoTR

For time formatting only, I've created a PR that makes it modifiable in DayJS locale config.

See flarum/framework4029.

Eric_Lian

reviewed, need to improve some details