DEV Community: Todd Anglin

Using Graph Explorer to Get Sample Data via REST

Todd Anglin — Mon, 27 Jul 2020 22:33:24 +0000

Here's the scenario: you've got an idea for an app that includes data from Microsoft's Graph API. You want to mock up the concept using dummy data from Graph API, and you don't want to jump through hoops writing "real code" around authentication.

What do you do?

Graph Explorer to the rescue

For the unfamiliar, Graph Explorer is a browser-based tool that makes it easy to...well, explore the vast capabilities of the Graph API. You can sign in to Graph Explorer to see your own data as you explore, or you can browse anonymously and get sample dummy data.

And really, if you work at a company that uses M365 (and most of us do) and you have not yet explored Graph API, do yourself a favor and check it out today. Much like social graphs do for consumer applications, Graph API puts tons of valuable information about your organization right at your developer finger tips. You are one REST call away from listing the members of your team or displaying a contact card in your app powered by the M365 directory. But I digress.

Graph Explorer. Dummy data. Your app concept.

Graph Explorer provides sample data when making anonymous requests to Graph API endpoints. For example, if we call this endpoint in Graph Explorer anonymously: https://graph.microsoft.com/v1.0/me/photo/$value. We get this image:

Easy peasy.

But if we take that same REST endpoint and try to access the sample data outside of Graph Explorer, we'll be met with a 401: Unauthorized error.

Accessing Graph Explorer sample data via REST

The solution to our problem lies in the API proxy that Graph Explorer uses in the browser. Inspecting network traffic for a Graph Explorer request reveals all calls go through a sandbox proxy:

https://proxy.apisandbox.msdn.microsoft.com/svc

The Graph API endpoint is passed as a URL encoded query string value. In the case of the profile photo endpoint:

?url=https:%2F%2Fgraph.microsoft.com%2Fv1.0%2Fme%2Fphoto%2F$value

The request will still fail, however, until you add the following HTTP header to your request (exactly as-is...no need to change the token value):

Authorization: Bearer {token:https://graph.microsoft.com/}

And, whala!✨ Graph Explorer sample data via REST!

Try it out with this interactive sample on JSBin

Get your own sample data

Using Graph Explorer's sample data is a convenient, quick-and-dirty solution for a design mockup or simple demo, but eventually you'll likely want more control over your sample data...and a place where you can test your app with Graph integration before deploying. And for that, you you'll want your own M365 sandbox!

Creating a M365 developer sandbox is free and easy:

Visit the M365 Developer Program page
Sign-up for free
Create your personal M365 sandbox

This gives you a sandbox URL, sandbox domain, and sandbox admin user account you can use to configure and play with M365 (and Graph) to your heart's content. Microsoft even provides sample data packs that add useful demo data to your environment with a single click (like additional sample users and profiles).

Now, when you authenticate using your sandbox account, you will see your personal sandbox data in Graph Explorer (or anywhere you access the Graph API). This is useful for any M365 demo where you don't want to expose the "real" data from your organization.

There you have it. A quick and easy way to grab Graph Explorer sample data, and a more robust path for creating a M365 developer sandbox.

PublishTo.Dev: Scheduling article publishing on dev.to

Todd Anglin — Tue, 30 Jul 2019 14:35:33 +0000

It's 11 PM.

You've finally put the finishing touches on your next masterpiece article on dev.to. You can't wait to share it with the world and start collecting those ❤️ and 🦄.

You move your cursor to that 'Publish' button, but then pause...

Should you publish the article now and risk getting buried in the morning's headlines? Should you set an alarm and try to remember to return to your draft and click 'Publish' at the right moment?

It's a conundrum and it's too late to think this hard.

I have a solution: PublishTo.Dev. A simple tool for dev.to authors that lets you choose the exact date and time you want your draft article to go live. Just choose a time, schedule your article, and go to bed knowing your content will land at the perfect time.

What is PublishTo.Dev?

At its core, PublishTo.Dev is a scheduling service for dev.to authors. It uses the recently introduced dev.to API to publish draft articles on a specific date and time. Well, I'll let this video explain.

There are 3 primary components of this service:

A browser extension used for scheduling articles
An Azure serverless backend that handles the scheduling
A static site to review/cancel scheduled postings

The browser extension works with both Google Chrome and Microsoft Edge Insider. The extension can be installed directly from the Chrome Web Store (and eventually Microsoft Edge Extension store), OR loaded "unpacked" from the GitHub source.

PublishTo.Dev does not attempt to change the article authoring experience. It works on saved, unpublished drafts that have already been authored using existing tools. PublishTo.Dev is focused exclusively on scheduling articles.

The scheduling process

Let's take a look at how you schedule a draft article using PublishTo.Dev.

Setup

First, you need to install the browser extension. Follow the instructions in the GitHub repo or (if you're using Chrome) just install from the Store.

With the extension installed, there is a one-time configuration step to add your unique dev.to API access token. This is how PublishTo.Dev publishes on your behalf. Right-click on the extension icon in the browser and choose 'Options'. Alternatively, you can navigate to chrome://extensions or edge://extensions to get to the options page, too.

Here, you are asked for your API access token.

To get that, navigate to the settings account page on dev.to and generate a new token for PublishTo.Dev. Copy the token value and it to the extension options.

Scheduling

Now that you're all set up, let's schedule an article.

Navigate to a saved draft. You know you're on the right page when you see the big, red "Unpublished" banner at the top of your article. From here, click the browser extension icon and choose the date and time you want the article to go live.

Note: The selected publishing time must be in the future (obviously), up to 30 days from now. That is an arbitrary limit that may be removed in the future, but for now, articles can be scheduled up to a month in advance. When choosing a time, specific hours or minutes can be directly input in the calendar text boxes.

With your date and time selected, click "Schedule Post."

If all goes well, you'll see a confirmation message in the extension pop-up.

Rescheduling

Oops! You just remembered that Wednesdays are better for your content than Mondays. How do you change your publishing schedule?

Simple. Just revisit the unpublished draft that needs to be rescheduled, and follow the original process. As long as the article has not yet been published, the new scheduled time will override the previous schedule.

Reviewing and Cancelling Schedules

While the browser extension is used for all article scheduling, a separate website is available for reviewing the status of scheduled articles.

To use the website, simply enter the same dev.to API access token configured with your browser extension and click "Get Scheduled Posts."

If you have scheduled articles, they will be displayed along with one of the following status indicators:

Published: Successfully published scheduled article
Pending: Article waiting to publish at scheduled time
Failed: Something went wrong and the article did not publish at scheduled time
Cancelled: Scheduled publishing was cancelled by the author (you)

Any article in the Pending state can be cancelled if you no longer want it to be published automatically. Just click the "Cancel" button on the row for that post.

If you decide to reschedule a Cancelled post in the future, just follow the original scheduling process and the article will be rescheduled. The only state that is "final" is Published. A published post cannot be republished or unpublished using PublishTo.Dev.

How does this work?

Behind the scenes, the heavy lifting for PublishTo.Dev is made possible by Azure Durable Functions. Durable Functions are perfectly suited for dealing with long-running, async tasks, only actively running (and billing) when something needs to be done between periods of waiting. The wait could be seconds, minutes, hours, days...or longer*.

(*Durable function timers cannot last longer than 7 days today, BUT...that is a limit that's being removed AND there are workarounds today for setting longer timers. I'll get in to that in another post.)

In the case of PublishTo.Dev, a serverless function runs when an article is initially scheduled, and then using a durable function timer, "hibernates" until it's time to publish the post. This eliminates the need to do any kind of interval polling to know when a post needs to be published.

When the scheduled publish time arrives, the durable function automatically wakes up and tries to publish the post using the dev.to API.

Durable functions are good for many different kinds of long-running, async scenarios. In fact, the docs highlight six common scenarios, like chaining async functions or even waiting on human input, where durable functions make your life much easier.

In future articles, I will expand on the technical implementation of PublishTo.Dev. Stay tuned for that.

Putting it all together

From the outset, the goal was to provide an easy way to schedule post publishing, and PublishTo.Dev accomplishes that. Or, it does for me.

Let me know what you think. How does it work for you? How can it be a more useful utility?

One day, I fully expect dev.to will support native post scheduling and eliminate the need for this tool, but until then, I hope it helps you improve your publishing workflow.

Testing the Dev.To API for Publishing

Todd Anglin — Mon, 29 Jul 2019 05:15:26 +0000

There's really no other way to say it: this post is a test.

For the last week, I've been working on a new tool that leverages the DevTo API to help authors schedule publishing time for new posts. I only recently started publishing to this platform, and was surprised to discover scheduled publishing not available. Fortunately, there is an API, so I set out to close the gap.

There is no sandbox for the API, though, and I clearly did not want to publish a bunch of spam during development and testing. So, until now, all testing has simply changed the title of a draft post at the scheduled "publishing" time. My assumption is that if everything else works, it should be a simple matter of changing the behavior to update the publish status instead of updating the title when development is done.

Well, let's see.

This post should go live automatically at 12:15 AM CDT. Hey. It's a test. If it's going to fail, let's fail when no one's watching.

But if you're reading this at 12:15 AM...it worked! 🎉

And that means I've got a lot more to share this week about how it was built, how it works, and how you can use it, too. Stay tuned.

Upgrading Older NativeScript Apps to Use Webpack

Todd Anglin — Thu, 18 Jul 2019 14:30:43 +0000

"Older" app sounds so negative.

And I'm not a fan of "legacy," "heritage," or "aging."

Let's go with "well loved" NativeScript apps.👍 No matter what you call them, they started before NativeScript fully embraced webpack, and now they need to join the webpack party to keep getting the latest NativeScript updates.

With NativeScript 5.4, the default build mode for NativeScript apps changed to use Webpack. And with this week's NativeScript 6.0 release 🎉, Webpack is the ONLY supported build mode. Webpack builds do offer big benefits, like reducing app package size and improving app performance (less JavaScript to load), but with that power comes a more complicated build configuration...especially for ~~an older~~ a well loved app that did not start with the Angular or Vue templates (that work with webpack out of the gate).

I recently updated my smart home controller app from NativeScript 5.1 to 5.4 and made the big switch to webpack. My app started in 2015, so it doesn't use Angular or Vue, but it does use TypeScript. My upgrade was anything but smooth, but hopefully my pain will be your gain. Here are some tips that will hopefully help make your NativeScript upgrade to webpack easier.

Start the upgrade

Clearly, the first thing we need to do is upgrade our environment and project to the latest version of NativeScript. As of this week, that's {N} 6.0. Upgrade the CLI with:

$ npm install -g nativescript

NOTE: When I went through this process, I updated to {N} 5.4, but much of the advice should still apply for {N} projects adopting webpack for the first time with {N} 6.0.

Then, in your project, update the package.json to use the latest versions of tns-ios, tns-android and tns-core-modules. It's generally a good idea to consider upgrading other dependencies and plugins at this time, too. In fact, with {N} 6.0, there is a new CLI command that will auto update some of these NativeScript dependencies for you!

$ tns migrate

When doing framework upgrades, I always delete the generated platforms, hooks and node_modules folders to minimize problems caused by cached assets. Once those folders are deleted, they can be regenerated with:

$ tns install

If your project is adding webpack for the first time, the install process will ask if you want to switch to webpack builds and will generate the required webpack.config.js and update the dev dependencies in package.json.

Delete old generated JavaScript files

When you use TypeScript with NativeScript pre-webpack, the build process automatically compiles the .ts to .js in your working directory and then syncs the .js to the device or simulator. With webpack builds, .js files don't get generated in the working directory. That's great! But...if you forget to clean-out the old generated .js files, it can create some real debugging head aches. (Ask me how I know...)

So, first things first. Good hygiene. Clean out generated files from your working directory. If you are using git, this can be done quickly with a command like:

$ git clean -fX

This command will remove all ignored files from the working directory.

If you switch to webpack builds, and it seems like the changes you are making in your TypeScript are not working on the device, this is a likely cause.

Rename files to register as modules

This is the big one. If you are upgrading a non-Angular/Vue NativeScript project, there is a good chance that you have your own convention for naming files and views in your project. With the default NativeScript webpack configuration, module file names must include page or root. If one of these two words is not in the file name, it will not be registered as a module.

EDIT: With the final release of {N} 6.0, the default webpack configuration was changed to include all modules in your project. This improves backward compatibility and it means you don't have to rename files.👍 If you are adopting webpack with an upgrade to {N} 5.4, all of this still applies. And, if you still DO decide you want to adopt the standard {N} file naming convention, the tips that follow should help you do that more easily.

There are two solutions:

Modify the webpack configuration (in webpack.config.js) to work with existing file names
Rename all view file names so they will be registered as modules

While renaming a BUNCH of files is daunting (and has some cascading impacts), I ultimately opted to go down this route. It's a one time tax and it will make future NativeScript upgrades easier.

Where my project previously had files like:

settings.xml
settings.css
settings.ts

To work with webpack, those files are now:

settings-page.xml
settings-page.css
settings-page.ts

My project also has a lot of "partial" views that are dynamically composed at runtime. Using page or root in these file names felt wrong, so I slightly modified the webpack.config.js to accommodate a "widget" option:

registerModules: /(root|page|widget)\.(xml|css|js|ts|scss)$/

This change is made in webpack.config.js > config > module > rules > loader options.

Meanwhile, TypeScript files that are not associated with a view do not need to be renamed. They will get picked-up by the separate ts-loader webpack configuration and work properly. Said to say, you don't need to rename every file.

Clean-up the rename mess

You've just renamed ALL of the files associated with views in your app. There's a good chance you broke some code if you use any of the following APIs that expect file names and paths:

.navigate
.showModal
builder.load or builder.parse

Search your code base for any occurrences of these API calls and update the file names to match the new webpack-friendly names. This will catch a lot of the common problems that file renaming can have on your code. If you are importing (or require()ing) any views programmatically, those paths must be updated, too.

Relative path changes

With webpack, relative path resolution can work differently than pre-webpack builds. This applies mostly to the way relative paths are resolved in .xml views. Fortunately, the "~/" relative to root syntax works very well everywhere with webpack, so any place you are using relative path navigation can be converted to ues the ~/ syntax.

For example, my app had several views importing a local custom component like this:

<Page xmlns:ui="../../shared/ui/loadingSpinner"

To make that work with webpack, it now looks like this:

<Page xmlns:ui="~/shared/ui/loadingSpinner-widget"

(Don't forget the file renaming.)

This works in TypeScript files for import statements, too. It's probably a good idea to use ~/ everywhere, but webpack won't break relative paths in code.

`Frame` element is now required

This should be a quick and easy fix, but critical nonetheless. Around the time of {N} 5.0, support for multiple frame elements was added so that more complex views could be achieved with NativeScript (think: independent navigation in a split view). Until now, if you did not manually add a frame element to your .xml view, NativeScript could create it implicitly. With webpack, a missing frame element will cause a runtime error.

For most apps, only one frame is needed in the "root" view. This is the view in which all other "page" views will load. If your app does not have a "root" view:

Create a new top level view with "root" in the name (ex: myapp-root.xml)
In the new root view, add the following XML (with a reference to whatever your default "page" should be)

<Frame id="my-app-root" defaultPage="views/myApp-page"></Frame>

Update your app.ts to load the root module when your app starts

app.run({ moduleName: "views/myapp-root" });

As you can gather, NativeScript with webpack builds is like running NativeScript in "strict" mode.

Builder `parse` vs `load`

If you dynamically load modules at runtime using the builder API, you will likely need to update your code to use builder.parse instead of builder.load. Webpack pre-registers and loads JavaScript and XML at runtime, and this can create trouble for the builder. In short, the builder attempts to load something that has already been loaded (by webpack) at runtime. (There is more discussion on GitHub in this issue.)

To fix this problem in my code, I changed this:

let newViewJs = require("views/dynamicView.js");
let newView = builder.load("views/dynamicView.xml", newViewJs);

To this:

let newViewJs = require("~/views/dynamicView.ts");
let newView = builder.parse(<string>require("~/views/dynamicView-widget.xml"), newViewJs);

We are now looking for these TypeScript and XML paths (as registered with webpack) and loading the resources from webpack's compiled, minified runtime resources.

Frankly, this feels hacky. There could be a better way. And it appears the project is actively refactoring around these APIs.

Debugging the errors

Even with the most thorough upgrade, you are likely to hit some new webpack related runtime errors when you first fire-up your app. Here are two common errors I hit and how I worked through them:

Fixing `Module not found` errors

I hit this error a lot when I first started trying to run my webpack built NativeScript project. In short, this error indicates that some path configured in your app (like the moduleName used by your app.ts on startup or a navigation path) can't be found in the registered webpack modules. Steps to resolve:

Make sure the module is actually registered. I didn't realize I had to change my file names to properly register the modules when I first upgraded, so that knowledge should already save you some time. Using the webpack "build reports" also helped me troubleshoot.

$ tns build ios --env.report

This creates a folder called report with a HTML and JSON doc that can be analyzed with tools like this. For relative webpack n00bs (like me), this report helps understand what webpack is doing.
Make sure the file name in code is correct. Assuming you took the path I did and renamed files, make sure the code is looking for the new file name with page, root or whatever additional tokens you've added to your webpack.config.js
Make sure JSON imports include a file extension. There were a few places in my app where I was directly require-ing a JSON file (usually to load some static configuration values). Pre-webpack, these imports did not require an explicit file extension, so this worked:

let config = require("../shared/config");

That doesn't match a registered path with webpack, so to work now, the file extension must be added:

let config = require("../shared/config.json");

As an aside, if you are loading static JSON resources in your project using local HTTP (and not explicitly require()ing), you will need to further update the webpack.config.js to load these static resources when your app is built.

    new CopyWebpackPlugin([
                { from: { glob: "assets/*.json" } }, //<- Add this
                { from: { glob: "fonts/**" } },
                { from: { glob: "**/*.jpg" } },
                { from: { glob: "**/*.png" } },
                ...

Fixing `Module parse failed` errors

Another common error I ran in to was this Module parse failed error, usually along with Unexpected token or Unexpected character log messages.

In my case, all of these errors were caused by accidentally registering files as modules that did not need to be. It's likely an edge case when doing a NativeScript upgrade like this, but if you find yourself head scratching with this error, double check that you're not inadvertently loading files as modules.

For reference, the wonky file in my project that caused these inadvertent errors was trying to dynamically require files like this:

let instance = require(`${dynamicPath}`);

Don't do that with webpack.

Double-check for circular references in barrel files

There's NO WAY I added a circular reference to my app.

I know better. I wouldn't do that.

Leave it to webpack to serve me some humble pie. Circular references that somebody added (checks contributor count: 1 😬) did not have any negative affect on the app before webpack, but once Mr. Strict joined the party, they triggered app crashes on startup.

These circular references crept in to my code via "barrel" files. Basically, convenience modules that re-export lots of related modules to simplify imports later. It's a concept borrowed from Angular. For example, here is a barrel file from my app:

app-factories.ts

export * from "./BaseController.factory";
export * from "./SceneProvider.factory";
export * from "./CameraProvider.factory";
export * from "./ThermostatProvider.factory";

Using this barrel file simplifies an import like this:

import { BaseController, SceneProvider, CameraProvider } from "~/providers/app-factories";

My mistake was accidentally using a barrel file short cut in a file that was exported by that barrel file. Webpack made me aware of my error, but the error messages were cryptic and the problem was not immediately obvious. Lesson learned: webpack may expose errors in your code that didn't stop your app from running previously.

Next Steps

Phew. It took some heavy lifting, but with a little debugging my app is now running on NativeScript 5.4 and working with webpack builds. It's also ready for NativeScript 6.0, which should now be a quick and easy upgrade. 🤞

There are a few more potential "gotchas" when upgrading to {N} 6.0 that the NativeScript team highlighted in a new blog post this week, so be sure to check that out for additional tips.

With the foundation of my app updated, my next step is to address the app backend and start connecting with Azure. Now the real fun can begin! 'Til then, I hope these lessons learned through pain will make your big webpack upgrades for well loved NativeScript apps easier.

Removing Short Imports in NativeScript, the Easy Way (with VS Code)

Todd Anglin — Wed, 17 Jul 2019 03:42:58 +0000

As NativeScript continues to evolve, some of the features that made sense in 2015 are creating more trouble than they're worth in 2019. One such feature is the so called "short import."

Short imports were intended to improve the developer experience by saving a few key strokes. Instead of this:

import { device } from 'tns-core-modules/platform'

A developer could simply use:

import { device } from 'platform'

It's convenient, but it has created unintended side effects. And with great tooling like VS Code that can automatically add imports, the value of this feature low.

So, now it's deprecated (as of {N} 5.2). Read all about it on the NativeScript blogs.

Now what?

While short imports still work, they will become a real problem with NativeScript 6.0, when webpack becomes the default and only available {N} build system. Webpack expects the full import path, so short imports quickly cause webpack problems.

But if you are maintaining an app that has been around for a while, removing short imports could be quite a chore. In my case, the app I was updating had more than 275 short imports to fix!

I started to fix the imports manually and quickly realized that was a mistake.

If only there was a way to automatically fix all these imports...

VS Code (and RegEx) to the rescue

Everyone knows that VS Code has great search and replace tools, but what may not be as obvious is that you can use regular expressions in the search and replace. Simply toggle "Use Regular Expressions" on and use standard JavaScript regex in the Search, and use $1, $2, etc to include matching groups in the Replace.

NOTE: To run really advanced regex searches with backreferences and lookaround (like we'll do today) does require a setting change in VS Code. Go to Settings > Features > Search > Use PCRE2 and check the box to enable these extra capabilities. See the VS Code docs for more context.

And I know, I know. If you have a problem and use RegEx to solve it, now you have two problems. But it beats the tedious alternative.

RegEx to find short imports

The trick to building the right regular expression for this task is trying find short imports for things that should have the tns-core-modules prefix while avoiding imports for "non-core" modules AND imports that already have the correct long format.

Fortunately, most NativeScript modules follow a similar convention:

Core modules use "plain" names with no prefix (like application or ui/layout)
Non-core modules usually prefix the module name with nativescript- or ns-
Local modules referenced by path usually start with ./ or ../ or ~/

By example, we want to FIND imports that look like this:

import * as imageSource from "image-source";
import * as util from "utils/utils";
import { Image } from "ui/image";

While AVOIDING imports that look like this:

import { Settings } from "../models/app-models";
import * as firebase from "nativescript-plugin-firebase";
import { Color } from "tns-core-modules/color/color";

AND THEN, when we have a match, we want to insert "tns-core-modules/" in front of the import path while keeping the rest of the line the same.

Put it all together, and we get this search regex:

(from \")(?!nativescript)(?!ns)(?!tns-core-modules)((?:[\w\-\/])+)(\")

Since regex always looks like a cat walked across your keyboard, let's explain in english:

Start finding imports by searching for from " (including the quote) (and store in matching group 1)...
Followed by any number of word characters OR - (dashes) OR / (whacks)(and store in matching group 2)...
BUT ignore if the matching group contains the words nativescript or ns or tns-core-modules
- These are likely non-core modules OR imports that already have the correct long format
And finally, match the trailing " (quote)

This combo does a remarkably accurate job of finding the imports we want while ignoring everything else. You can play with a working version of this regex using Regexr in your browser to experiment with what it matches and misses.

When running the search in VS Code, to avoid false positives, you obviously also want to exclude files and folders that are not part of your code, like node_modules, platforms, *.js (assuming you're using TypeScript), .git.

Replace syntax

When the search finds a match to this pattern, it will create three matching groups with these values:

from "
[name of matched module]
"

For example, when the following line is matched:

import { Image } from "ui/image";

The matching groups will contain:

from "
ui/image
"

We want to insert tns-core-modules/ between group 1 and group 2. Using VS Code, our replace syntax is:

$1tns-core-modules/$2$3

Boom! Job done. Almost...

Another search and replace pass

If you're using the plain JavaScript require() syntax to import modules, you clearly need a different search pattern. Even in my TypeScript-based app, I had a handful of imports done with require() for reasons specific to module implementation.

Conceptually, the search regex we need is similar to above:

(require\(\")(globals)+(\"\))

This pattern matches:

require("
globals
")

You could modify the "globals" pattern if you need a wider search. In my case, this was the only require() in my app that needed the tns-core-modules prefix.

The replace pattern is the same as before:

$1tns-core-modules/$2$3

Wrap up

Hopefully you've learned two things in this post:

Eliminating short imports in your NativeScript app doesn't have to be tedious manual process
VS Code search and replace is REALLY powerful when combined with regex and matching groups