Msg refactoring

[TornaxO7]

Hi! As the title says, I'm talking about the msg_entity.rs file or to be more precisely the Msg struct.

I'm wondering if we should improve the methods of the Msg struct because it's
very hard to write some tests for it, due to the magic strings like this "unknown sender" or "unknown date" because if you want to write some tests for it, then you'd have to copy+paste those strings which makes it a little bit hard to maintain and to test.

In my opinion, it's a sign that we need to restructure the code a little bit. What do you think about that? Do you agree to this?

[soywod]

I do not think that it is the right moment (there is so much to do before), but I agree that the Msg struct needs a tiny lifting. What do you propose?

[TornaxO7]

Hm... well, you're moving the lib-stuff out and I think that this should be the first step, because if this is done, then we can do changes to Msg without being afraid, that the moving will be more difficult afterwards. So my suggestion is the following:

Keep focussing on the moving first, that has definitely the highest priority at the moment. Doing changes now to the Msg might end up refactoring more LOC but I think small changes can be still accepted. I'd suggest to plan a good abstraction of the lib after the moving this should help to write better tests and hopefully attract less bugs. What do you think about it?

Anyways, is it somehow possible to help you with the moving of the lib?

[soywod]

I find your proposition reasonable! The main objective is to move everything to the lib folder without refactoring. The aim is really to move stuff without changing anything. Then we can change some stuff. The next priority will be #344, which will introduce breaking changes. But it is really necessary to have a solid configuration. There is also the composer and the synchronizer, which are needed for a better UX (in fact it is everything mentioned in #345). In parallel of that, we need to fix bugs.

Anyways, is it somehow possible to help you with the moving of the lib?

Not that much at the moment, but where Himalaya needs help right now is bugs. Then config refactor then composer!