What is the best place to start learning React, TypeScript, and Jimu?

2329
8
Jump to solution
10-27-2023 04:16 PM
DanielWebb
Occasional Contributor

This seems like the best place to ask these questions.

I’m looking ahead to the retirement of Web AppBuilder and want to start grappling with custom widgets in Experience Builder. I have the developer stuff downloaded and can add in custom widgets. Now I need to learn how to create my own custom widgets from scratch.

Experience Builder is built with React.js and TypeScript and I saw something about Jimu (whatever that is) but I don't know these things.

My questions are these:

  1. Which should I focus on learning first, React or TypeScript? In other words, which will provide the better grounding for the other? OR, is it best to learn them both at the same time?
  2. Are there any online training courses for React and TypeScript that anyone would recommend (like courses in Udemy or something like that)?
  3. Does Esri plan to have any training for beginners in React/TypeScript? (So far, the 1-hour YouTube and Dev Summit videos assume the developer knows all about Jimu, TypeScript, React, etc. I’m sure there must be others like me who don’t know anything about those things and get lost trying to follow along.)

Any input on where to begin would be helpful. Thanks!

1 Solution

Accepted Solutions
JeffreyThompson2
MVP Regular Contributor

Jimu is the 4.X ArcGIS Javascript API. The docs on the ESRI site cover the API very well. It is very important to familiarize yourself with the API as Experience Builder is really just a skin over the API, so you will be interacting with the API directly if you do any custom widget development.

TypeScript is a superset of Javascript. It is useful mostly in the extra Intellisense that comes pre-packaged in Experience Builder. You do not need to worry about explicitly learning TypeScript because all of Javascript is valid TypeScript, but you may find it occasionally useful to define your own types if you build any complex objects.

React is vital to learn for custom widget development. Probably even more important than the Javascript API. React has a very steep learning curve as it works very differently than plain Javascript. It would be a good idea to spend some time learning React before getting into Experience Builder. The official docs  have a good guide with little coding tutorials built in. https://react.dev/learn YouTube has many good React tutorials, but make sure that you are watching stuff from 2020 or later. React was majorly revamped in 2018 when Hooks were introduced, so all the pre-Hooks material is now out-of-date. If you see classes, it is the old style of React. Classes are still valid React, React has no plans to ever remove classes, and many Experience Builder components are class based, but you should never use class based components by choice.

Don't expect ESRI to help you learn React.   

GIS Developer
City of Arlington, Texas

View solution in original post

8 Replies
Brian_Wilson
Occasional Contributor III

I know I will offend many serious diligent programmers with this, but, you can safely ignore Typescript forever. At least you can play around with some React apps without even thinking about Typescript.

Outside of the Esri world, I have done a fair bit of React programming and every time I try to jump into Typescript I give up after a few days and strip it all out of my code. At this point I doubt I will ever touch it again.

I feel pretty much that I can make horrendous errors programming in any "type safe" languages like C# and Java and I can make wonderful things happen in JavaScript and Python. So why make it harder on myself?

I am sure if the app I was writing was 5000+ lines and I was collaborating with a team, I'd learn to love Typescript but I work alone and my apps are always as small as I can make them and get away with it.

If you really really feel passionate about Typescript you should learn it right away. Kind of like doing Test Driven Development. I've never embraced that either. My unit testing is not done the officially mandated ways either. So much to learn, but at the end of the day I have to finish projects and no one else cares if they are done the "right" way.

MichaelLev
Occasional Contributor III

@Brian_Wilson , I was impressed by your attitude to programming, so reading "My unit testing ..." made me request if you can elaborate on your way of testing, so I can adopt something from it.

0 Kudos
Brian_Wilson
Occasional Contributor III

There are tools designed for unit testing but haven't had time to learn yet. In Python I break the code up and each file has a section if __name__ == "__main__":... so it can run independently and I put tests in there. So for example if you have a package "unit_conversions.py" at the bottom there would be a batch of assertions like

if __name__ == "__main__":
  assert(d_to_dms(-123) == "W123 00 00")
  assert(d_to_dms(-123.5) == "W123 30 00")
  assert(dms_to_d("W123 00 00") == -123)
  assert(dms_to_d("W123 30 00") == -123.5)
  print("All tests ran.")

Then every time something goes sideways with my conversions or I want to make them do more, I add test cases and I can feel confident the changes actually work.

In PHP and JavaScript I have a separate URL that I can hit, then I can put a bunch of code in there to test function calls with a standard set of arguments. So there will be a "secret" web page, for example "test/unittest.php" or "test/test.html" that invokes a script with assertions, same idea as the Python.

Each time I find edge conditions in my data that screw up my app, I add those data to test cases. Often this saves me from having to type the same input into a form a zillion times while testing. I just hit one URL in a browser. If the page loads, great. If it loads partway I can look at it in either the browser (F12) or in a debugger in VSCode

That's about it.

MichaelLev
Occasional Contributor III

@Brian_Wilson , thanks.

I deveop custom widgets on WAB and now I start moving to EXB (both Developer Edition), and the web apps are used by many users thrughout the country. I work on JS (not Python).

I developed up to now one "web service" that have a log of each call and also have errlog. I also inserted in its code that every some hours it runs on pre designed "fake input" and logs accordingly. 

My main work are  web apps that are run only interactively by users. I can not test them by "run test".

I am already using url optional parameters to log debug info to console in key points. This is used only by me when developing or testing.

What I take from you is the additional idea of inserting "traps" in the code to check the program while it is running the regular way by the users. I'll sum up:

1. I'll implant "console.assert" in key points in code to "trap" when things are not ok. This will be effective mainly when I run the web app, because users regularly do not examine the console.

2. In order to "trap" and log errors when users are running the web app, I think that "assert" is not effective, so I'll do:

2.1.  Pay attention to log all "try-catch" failures (and user command failures) to some DB (I already have such DB) to be examined by me and by the customer service from time to time.

2.2. Insert "If" blocks in key points, to "trap" unexpected behaviors log them to same DB mentioned above.

2.3 Maybe I'll use my assert function either to log to DB or throw error (which will be logged to DB). The advantage of this is that I can search for all "assert" in my code, to examine wher I do the checks.

const assert = function(condition, message) {
    if (!condition)
        throw Error('Assert failed: ' + (message || ''));
};

 

JeffreyThompson2
MVP Regular Contributor

Jimu is the 4.X ArcGIS Javascript API. The docs on the ESRI site cover the API very well. It is very important to familiarize yourself with the API as Experience Builder is really just a skin over the API, so you will be interacting with the API directly if you do any custom widget development.

TypeScript is a superset of Javascript. It is useful mostly in the extra Intellisense that comes pre-packaged in Experience Builder. You do not need to worry about explicitly learning TypeScript because all of Javascript is valid TypeScript, but you may find it occasionally useful to define your own types if you build any complex objects.

React is vital to learn for custom widget development. Probably even more important than the Javascript API. React has a very steep learning curve as it works very differently than plain Javascript. It would be a good idea to spend some time learning React before getting into Experience Builder. The official docs  have a good guide with little coding tutorials built in. https://react.dev/learn YouTube has many good React tutorials, but make sure that you are watching stuff from 2020 or later. React was majorly revamped in 2018 when Hooks were introduced, so all the pre-Hooks material is now out-of-date. If you see classes, it is the old style of React. Classes are still valid React, React has no plans to ever remove classes, and many Experience Builder components are class based, but you should never use class based components by choice.

Don't expect ESRI to help you learn React.   

GIS Developer
City of Arlington, Texas
Brian_Wilson
Occasional Contributor III

Yes-- the part about out of date React docs should be in BOLD!

BE 100% certain the React tutorial you are reading is current.

There are 100's of excellent React tutorials that are sadly out of date now. I wish the authors would take them down! I wasted a lot of time on that. You can still use old code and learn the old ways but over time React has gotten easier to use so skip the old stuff.

 

TimWestern
New Contributor III

I would Bold, underscore, and Italicize this.

It's not just the millions of out of date react samples you may find.  There are earlier examples, tutorials, and videos on youtube of working with experience builder (some of which a trained programmer may notice that the api or properties of some types in Jimu changed, but a GIS Analyst with less programming experience might not.)  Having run into this myself, I'd encourage you to pay attention to dates on samples if they are there, and if its a while ago, go into the developer section for API reference and look up the components you are working on you may find better help than trying to brute force through learning on an older version of the Experience Builder App and reference APIs.

DanielWebb
Occasional Contributor

I wish I could mark two answers as correct. You both were very helpful. Thanks!

From what I’m reading here are my takeaways:

Sounds like I don’t even need to learn TypeScript. I can write an Experience Builder custom widget in normal JavaScript, and it will work?

The most up-to-date React is the main thing I need to focus on right now, even before ExB widgets. (And stay away from classes in React.)

This gives me a good start. Thanks again!