Upgrade to React

[amitguptagwl]

Imglab is currently implemented using jQuery. I believe it should be migrated to react app. Discussion and PRs are welcome.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[amitguptagwl]

Used riot js for gallery and toolbar

[alextychan]

@amitguptagwl, would you consider migrating to react or vue? I find that riot.js doesn't scale that well, especially when the number of files we have is growing.

I have some experience with Vue js and I find it to be easy to use. It's also pretty lightweight and easier to learn as compared to React.

Official website: https://vuejs.org/v2/guide/ Github repo: https://github.com/vuejs/vue

[amitguptagwl]

I agree that there are some issues with riotjs and I've no issue if we migrate. But PRs may take longer time for review in starting. I'll create a separate branch "vue" for that.

[alextychan]

@amitguptagwl, just a quick update. I'm still working on porting this project over to Vue.js. It's taking a while.

[amitguptagwl]

Please remember there is one PR in progress whoever completes first will not face conflict issue

[alextychan]

@amitguptagwl, I would like to ask for help with supporting the nimn file format. The problem I'm facing is as follows. The objects that store the data for shape and feature points all contains dynamic keys. E.g

var shapes = {
  [shape_id_1]: {
    type: "Rectangle",
    featurePointIds: [ "feature_point_id_1", "feature_point_id_2", ...]
  }
},

var featurePoints = {
  [feature_point_id_1]: {
    x: 1,
    y: 1
  },
  [feature_point_id_1]: {
    x: 2,
    y: 2
  }
}

I've found that nimn doesn't support dynamic keys well as object structure has to be provided during the encoding and decoding process. One workaround I'm thinking of is to store the object structure created from nimnjs-schema-builder by using JSON.stringify. But if we're going that route then it might as well be easier to just use JSON.stringify.

The dynamic keys are needed for me to flatten the store structure that's used to store the data.

[amitguptagwl]

there is a concept of "varmap" which let you save dynamic object. However, think twice you probably will not need it .

Moreover,

1. Please remember that this changes should work fine with previously saved nimn file.
2. I have to do some breaking changes in Nimn. But not getting the time for that. It'll require changes in imglab too.
3. We can provide an option to save data as json. But ..
   • We need to support nimn format in future
   • There are other formats too which accept json type. So we'll have to change import window.

I'll be in travel for next 2 days. So the delay can happen to answer or review anything.

[alextychan]

@amitguptagwl, could you provide an example of how to build an object structure with "varmap"? I couldn't find any examples the nimn specs.

[amitguptagwl]

Imglab is already saving data in nimn format. So I'm assuming that particular change should be there. Have you found any issue with that implementation? Because if you're gonna change any approach, we'll have to take care of backward compatibility.

On Tue 23 Oct, 2018, 1:24 PM Tai Yau, [email protected] wrote:

@amitguptagwl https://github.com/amitguptagwl, could you provide an example of how to build an object structure with "varmap"? I couldn't find any examples the nimn specs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NaturalIntelligence/imglab/issues/10#issuecomment-432136465, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVgKDW0FhRedPOhZxl4pEltuq4DUhWLks5unssygaJpZM4TkXed .

[alextychan]

Woops, forgot to take a look at the project itself and got stuck on the spec sheet. I'll work on it and seek help if I get stuck on anything. I've made quite a few changes and backward compatibility will be something to work on future iterations.

[amitguptagwl]

some detail about the decision of using nimn format.

About Nimn

I've created Nimn format around 8-10 months ago. It saves approx 60% space in comparison of JSON and it is around 2-3 times faster than JSON.stringify. However, when I heard about other data formats doing the same, I've planned some big changes in nimn format based on BigBit format.

Status

Nimn v2: rest to implement (need 2 weeks time) BigBit: rest to launch ( need 2 days time)

How it can benefit imglab

imglab was a good platform to try this format. The initial reason to use this format was not only to keep the size of the project file small but to integrate serverless collaboration. Unfortunately, that is still in the plan along with many other features.

serverless collaboration is till in plan and will be launched as separate project. It may need some funding as well

What to do

I've observed that many users labeled up to 400 images in one project. Considering, there are 68 landmark points in each image, I believe the size of the project file may reach to 1mb easily (rough estimation). And importing a big file, may require few seconds loading.

However, as this application runs completely on the client side, speed and size are secondary aspects currently.

Considering the fact that we should Design for the future, Code for the present, we may decide to save data in JSON format instead of nimn if we require any additional change. Because, everytime doing the change in project file format will impact user experience.

Alternatively, we can also think about protobuf.

[rohitkrishna094]

So I have two questions about this.

1. Has it already been decided that this project will be ported to Vue js only and not React?
2. I see that port to vue hasn't been done yet? Is there any roadmap for it or is that feature stale now?

If you plan to move to react, I would like to be involved as I have learnt react recently. I have never tried Vue though.

[amitguptagwl]

There is a separate branch for this transformation that you can have a look at. I believe Vue would be a better option.