RFC Sandcastle Features

The main intention behind adding React is that it is a powerful UI library, and it is being adopted by a lot of developers. Its rendering times are many times better than what can be achieved by Knockout, mainly because of the virtual DOM being used behind the scenes. It guaranteed that Sandcastle would be future proofed for atleast a couple of years.

That being said, I’m going to have to agree with Matt. As such, the huge benefit in rendering would not be visible in a light application like Sandcastle. As for modularity, my aim here was to just keep it simple and structured so that if anybody wishes to start contributing to Sandcastle, the application is structured in a way that it would be easy to start adding features. As a simple example, when we decided to add a new tab for CSS, it took me only 10 minutes to get that up since I could reuse the code editor component in the React app. I wouldn’t say that it would be hard to maintain or understand the application even if it were not modularised, but that was done just so that the application is structured from the beginning itself.

The only new libraries here are React and PubSub. JSX simply helps me to develop the application faster, since I can directly write HTML within the JS. Looking at the code in JSX, it is much easier to understand what’s going on than it would be to see the transpiled code in JS. I’ve added JSX as a dependency within Sandcastle right now, but I would remove this since we can directly pass the transpiled code to the Sandcastle app.

If there is no future plans to add any sort of collaborative editing, or a server side component, isomorphism provides no benefit to Sandcastle. The decision to use React was based on the assumption that there may be such a plan in the future.

As for maintaining the application, I’d go so far to say that the React application is much easier to maintain than a JQuery+Knockout application. In my research into developing an application like Sandcastle in React and Knockout, I definitely found React as an easier option.

These were the main reasons we decided to go with React. Like I said, it is based on some assumptions for the future scope of Sandcastle, and they might have been incorrect. If the community still feels the need to remove React and go with Knockout, we can do that.

@Patrick: Thanks for raising the Sandcastle examples point. Could you help me out with the CZML examples? I haven’t worked on CZML and do not know what sort of examples we are looking to add.

We would like to get some feedback from the community regarding fixed vs adjustable editor widths. Since we’re using bootstrap for the layout we were thinking of instead of a completely adjustable width we would have 3 discreet widths, a narrow, half and wide. Narrow would be 1/3 editor 2/3 viewer, normal both half screen, wide being 2/3 editor 1/3 viewer.

This is only for desktop and tablet layouts.

Hi,

Could you help me out with the CZML examples? I haven’t worked on CZML and do not know what sort of examples we are looking to add.

We need a series of very simple CZML examples that show off CZML’s individual features like the simple Cesium API examples we have for different geometries. Mike can help you propose the set of examples. To get started see these:

Since we’re using bootstrap for the layout we were thinking of instead of a completely adjustable width we would have 3 discreet widths, a narrow, half and wide. Narrow would be 1/3 editor 2/3 viewer, normal both half screen, wide being 2/3 editor 1/3 viewer.

When I use Sandcastle for debugging during development, I often move the slider so the Cesium window is big enough (without having to go fullscreen). I guess if the 1/3-2/3 approach is much easier to code, it might work OK-ish in this case, but I think it would be foreign to what most users expect.

Patrick

Aditya, just to try and close the loop on this. I’m still not convinced that there is any reason to use React (or pubsub) or any other new thirdparty libraries you might plan on introducing into Cesium. My preference would be to do everything with Knockout, jQuery, Bootstrap and the standard Cesium utility classes. Feel free to continue down your current path as long as you like, but unless there’s some substantial benefit I’m missing, I don’t expect a React based pull request to be accepted into master.

As for the adjustable width editor, I think it would be a shame if we lost it, but if it’s creating technical hurdles for you, I’m okay with temporarily losing the capability. We can always add it back at a later date.

As an aside, while I know Ed hasn’t chimed in on anything yet, I know he’s a big proponent of the variable width editor (but he wrote Sandcastle, so all of his biases are already built into the existing app :slight_smile:

Thanks for your help Matt. I’m working on a Knockout version right now and I should be done in the next couple of days. The adjustable width editor has been added and we’ve removed the discrete options since it does not seem intuitive.