Allow filtering messages by start / end date

[Pustur]

Currently the app allows to filter the messages based on start / end indices, would be cool to do the same but based on two dates as discussed in #14.

[Pustur]

Before tackling this feature I decided to do some major refactoring to the code because it was honestly in a pretty bad spot.

1. I replaced Create React App with Vite. Not only it's faster and less bloated, but it also allows me to update some eslint dependencies that I couldn't before.
2. I decided to use a proper tool to manage state. Without one, things really started to get messy. I went with Jotai and I found it quite nice to work with.
3. As a side effect of number 2, I also updated React to 18.1.0 because otherwise I had problems when using async atoms in Jotai.

I worked all weekend on this so I'd like if @thenicnic (or anyone else that stumbles on this discussion) could test the refactored app and report any problems that I may have missed.

The preview link is the following: https://6278456aa4d7b70008883fd7--whatsapp-chat-parser.netlify.app/

Thanks

[thenicnic]

Thanks for your good work! I summarize what I noticed so far:

• The reworked version doesn't run after just downloading it using "Save As" in Firefox (styling gets lost) but that's no big deal. I am using a computer that is completely offline so I just wrapped everything into a tiny nginx directory and corrected the path to index.js and it works perfectly in localhost.
• It's great that the menu button doesn't appear in print preview anymore, thank you! Export using Firefox "Save as PDF" together with unticking the "Print headers and footers" checkbox leads to a perfect result, including searchable text.
• Not an issue on your side but the message filter can a bit misleading if one just looks at the line numbers using a text editor for filtering: If there are messages that are split up into multiple lines, you get an offset between line number and message number. Your app counts the messages which is absolutely correct. A possible way to prevent people of using the text editor's lines would be showing the message number in the corner of the message bubbles. (Maybe it's possible to just pass the indexOf/findIndex of "messages" array from the main App.js to the MessageViewer.js and display it?)
• I edited the "_chat.txt" (cut off the lines I don't want to see) but had to repack it into a ZIP because otherwise the attachments weren't recognized (although they were in the same directory).
• Export as "viewable" HTML without the Dropzone area header bar would also be nice. Plus I don't know why the layout breaks doing this (as described in point 1).

Maybe I can do some of that by myself but I am completely lost at "compiling" this web app project into the "index.html" + "index.js" set from the sources so it would be cool if you could tell me which environment you are using.

[Pustur]

Hey, thanks for the great feedback.

A possible way to prevent people of using the text editor's lines would be showing the message number in the corner of the message bubbles.

It can easily be done. Will add in my todo.

I edited the "_chat.txt" (cut off the lines I don't want to see) but had to repack it into a ZIP because otherwise the attachments weren't recognized (although they were in the same directory).

Unfortunately that's just a limitation of the app, if you want to see the attachments you have to use a zip file.

Maybe I can do some of that by myself but I am completely lost at "compiling" this web app project into the "index.html" + "index.js" set from the sources so it would be cool if you could tell me which environment you are using.

To compile and run the app:

1. Clone the git repo
2. Install Node.js (I currently use 18.0.0)
3. Open a terminal in the root of the project and run npm install to install the dependencies (optionally with the --production flag to avoid installing development dependencies)
4. Run npm start to start a development server (while in this mode you can change the code and see the results immediately)
5. Run npm run build to build the compiled bundle that you'll find in the build/ folder (this is what I upload with every release).

To run the built files you can use any server

• If you have python installed you can use python -m SimpleHTTPServer or python3 -m http.server depending on the version you use
• Since you should already have Node.js + npm you can install a package with npm install --global http-server then call it with http-server

In both cases you should invoke the command from inside the build/ directory.

[Pustur]

New preview released: https://627eabf4a8f8800008d99802--whatsapp-chat-parser.netlify.app/

• Added index numbers on message bubble hover, or when holding the ctrl key
• Fixed crash when zip file doesn't contain a _chat.txt file

[Pustur]

I just wanted to say that after a lot of time some things have been released into the main site. (see release for what changed)

Unfortunately I don't think I'll have time to work much more on this project, so the "filtering by date" feature may never come 😔

[DaveKeehl]

I'm interested in contributing to this feature. Just a couple of questions:

• Should the filtering by date be applied before or after the messages limiting?
• Assuming that the filter by date is implemented as a new fieldset in the same fashion of the message limit, should each fieldset have its own "apply" button? I'm thinking it would perhaps be better to have only one submit button for the entire form, but I would like to know your opinion on this

[Pustur]

Hey @DaveKeehl thanks for your interest.

The way I see it, it doesn't make sense to have both filters active at the same time. There should be a radio button to select between the "index mode" and the "dates mode".
The fields for the mode that is not the selected one shoud be hidden.

With this structure I think it should be just one submit button that handles the form.

A bit of additional info on the "dates mode":

I think an <input type="date"> should be enough, it also allows to be limited with a min / max attribute

So for now no external libraries or fancy stuff is required for that part.

[DaveKeehl]

@Pustur I think we can close this issue now, since this feature has been implemented.