fix web compilation

[maxluchterhand1]

Instead of storing the ids of the isar collections as integers, I moved the generation of those integers (which are just hashes of the name property) to runtime. this way, the dart code does not contain integers that cannot be represented in javascript.

[maxluchterhand1]

I just realized that the hashing library (xxh3) itself also contains large integers that cannot be represented in javascript, fml.

../../.pub-cache/hosted/pub.dev/xxh3-1.0.1/lib/src/xxh3.dart:72:8: Error: The integer literal 0x9FB21C651E98DF25 can't be represented exactly in JavaScript.
Try changing the literal to something that can be represented in JavaScript. In JavaScript 0x9fb21c651e98e000 is the nearest value that can be represented exactly.
  h *= 0x9FB21C651E98DF25;
       ^^^^^^^^^^^^^^^^^^
../../.pub-cache/hosted/pub.dev/xxh3-1.0.1/lib/src/xxh3.dart:72:5: Error: A value of type 'num' can't be assigned to a variable of type 'int'.
  h *= 0x9FB21C651E98DF25;
    ^
../../.pub-cache/hosted/pub.dev/xxh3-1.0.1/lib/src/xxh3.dart:74:8: Error: The integer literal 0x9FB21C651E98DF25 can't be represented exactly in JavaScript.

However, I am pretty sure it is possible to implement the hashing algorithm in a JavaScript compatible way. I will continue working on this

[maxluchterhand1]

okay, I fixed the issue that I described in my previous comment in a very dirty way. basically, I just moved all of the code from https://pub.dev/packages/xxh3 into this package, and modified it in such a way that you can compile for javascript without getting the integer literal compile time error. however, the xxh3 algorithm still doesn't work in javascript, the exception is just moved to the runtime instead.

so basically, with my branch, you can import isar into your flutter project, use isar in all support platforms that are not web, and compile for web without errors. attempting to use isar on web will cause runtime errors.

why would this benefit anyone? we are using isar as part of a shared package that we use throughout many apps, including web apps. with the integer literal compilation error, we could no longer import that shared package in web apps and compile the app, even if we didn't use the isar part of the shared package in the web apps. and apparently, other people have similar issues. if you are one of those people/companies, you're welcome.

however, I find this solution pretty ugly. therefore, I am not sure whether this PR should really be merged. maybe you can use it as an inspiration to come up with a proper solution that actually WORKS on web, not just enables compilation. I, unfortunately, don't have time to continue down this rabbit hole

[vicenterusso]

Have you tried this?

#82

[maxluchterhand1]

Have you tried this?

#82

I tried that before I started working on this. I did not work. I can't remember what the exact problem was but I think the app wouldn't compile

[danielgomezriconeon]

@maxluchterhand1 and it works? Why it is not been merged?

[danielgomezriconeon]

I tried this but got this error:

  `lib/common/database/models/entity.isar_generator.g.part`.
This may indicate an issue in the generator, the input source code, or in the
source formatter.
Could not format because the source could not be parsed:

line 44, column 27 of .: Expected to find ')'.
   ╷
44 │       idGenerator: Closure: () => int from Function 'id':.,
   │                           ^
   ╵
line 54, column 27 of .: Expected to find ')'.
   ╷
54 │       idGenerator: Closure: () => int from Function 'id':.,
   │                           ^
   ╵