This release fixes some bugs related to periscope.toast on iOS, Safari, and mobile devices.
Shoutout to @aaronrai24 for helping test.
This release also adds perspective.context.view and perspective.context.component object references to the runJavaScript context. This allows you to reference the current calling component/view. Note, these are not available when targeting a remote session or page.
Full Change Log
@embr-modules/periscope-web@0.12.0
Minor Changes
dd8a25b: runJavaScript functions now expose perspective.context.component. This is the client-side ComponentModel of the component that made the runJavaScript function call.
This is undefined when targeting a specific session/page.
dd8a25b: runJavaScript functions now expose perspective.context.view, the client-side ViewModel of the view that made the runJavaScript call.
This is undefined when targeting a specific session/page.
Patch Changes
2aa9142: Toast container now smoothly transitions when docks are open/closed.
06455f1: Remove dock padding when screen size suggests a mobile device. This allows the toast to span the full device width when docks are present on mobile.
afa89e6: Move z-index to the toast root container. Resolves #435.
cb55367: Refactor to properly distribute functions between perspective-client and utils. utils should be usable by any React project, and perspective-client should contain all helpers that are specific to Perspective.
Hey @bmusson, the latest couple of releases seem to be missing the built modl files, not sure if this was intentional or something went awry? Do you have the modls available (i'm looking for periscope and charts at this stage). Cheers!
Client Resources are files compiled to JavaScript that are loaded by the Perspective client on launch.
There are currently two supported types:
TypeScript (supports JavaScript, TypeScript, JSX, and TSX)
CSS Modules
All Client Resources loaded and run on page load/refresh, serving as a direct, robust alternative to Markdown Injection. They can also provide React components, which can be used via a new dedicated React Perspective component or anywhere you would normally use an EmbeddedView.
Attached is an example project that demonstrates:
Writing React components.
Accessing the available system modules: (system:perspective and system:periscope)
Importing/exporting between Client Resources.
Using style classes from CSS Modules.
Rendering Client Resources inside of EmbeddedViews, using @/{path} syntax.
For external dependencies or complex libraries, is it possible to load files directly from a folder on the hard drive instead of defining them one by one inside the Designer’s Resources section? For example, could we configure a specific directory that the module can access and import files from at runtime, similar to how a web development module exposes a shared folder?
Hey @bmusson, I questioned a few weeks ago whether your Periscope module's EmbeddedView+ container might resolve the issue with IA's EmbeddedView container randomly not passing params through sometimes (or not-so sometimes!!) when you have nested views (even 2 layers deep), often where the params have dicts/objects and lists.
I've just done an upgrade from v8.1.42 to 8.1.51 and noticed that a lot of the EmbeddedView containers had these issues, so I moved some of the problem ones across to EmbeddedView+ and the issue went away entirely; I cannot get them to fail.
So I think the answer to my question is "yes", it does resolve the issue.
Although now my question to IA is: why is it still an issue??
I started this java GUI for the designer to facilitate easy switching between EmbeddedView and EmbeddedView+ because of this
(It just migrates the differently named props between the two since they're different [better, more consistent names in yours, imo])
I think that's fine to support it for versions 8.1.49+ , I personally wouldn't mind upgrading a client's gateway to the latest version of 8.1 to use it.