Is there a need for JavaScript in the position of xx in yy library block?

I was after a text search and replace block - didn't see one in the libraries so decided to write one - in pure Snap!

I used the position of library block in a couple of places and when I went to export my replace block into to my local library blocks folder, I realised that it was dependant on the position of block.

When this happens, I always have a look at the block that I'm depending on to see if I can easily copy/paste it's code so that my block doesn't have a dependancy (sometimes its very easy to do this - sometimes its not worth it/not possible)

Anyway - getting to the point of the shaggy dog story here :slight_smile: - I was suprised to see that it was written in JS!!!

And I thought to myself - surely there's no need for this to be in JS (I haven't tried to code it yet but my instinct says it should be possible to do it in Snap! - [Edit Done] )

Assuming I'm right, if there isn't a need for speed (and there usually isn't when dealing with word type stuff) should a block like this be written in JS?

I'm off to make sure it I can code in in pure Snap! otherwise this whole post has been a waste of time :slight_smile:

Change it to Snap! instead of Snap1 :slight_smile:

First attempt

(Might not handle edge cases but shows it's possible)

I like it. I wonder which edge cases you had in mind that it could not handle?

I didn't have any in mind but normally they crop up after extensive user testing :slight_smile:

But my first attempt seems to work OK even with rubbish input :slight_smile:

image

Here's a much easier way:


And it reports the length + 1 if it's not found, which is most logical imo.

Very nice :slight_smile:
But length + 1 isn't the Snap! way :slight_smile:

image

original block gives 0

image

Aha! Got it!


untitled script pic (18)
untitled script pic (19)

Using MOD in that way is very clever.

The whole purpose of that particular library is to make a handful of useful JS primitives available to Snap! programmers.

More generally, I see libraries as extensions to the Snap! language, rather than as programming exercises. So I'm happy to write them in JS, even while discouraging users from just using Snap! as an IDE for JS. (I don't mean that users should never use JS Function when needed, just that they shouldn't put all their effort into writing in JS.)

On my list of needed Snap! features is hybrid primitives. What this means is that the primitives that could have been written in Snap! itself except for speed issues will have an Edit option in their context menus, which will open a Block Editor on a Snap! version of that primitive, with a different name, maybe appending "(2)" like the Duplicate Block Definition option for custom blocks. That way, we keep the fast primitive available to the user who does it, but the user can also examine and edit the Snap! code. When we do that, we should (thanks for the idea) extend it to library functions written with JS Function that don't need to be.

P.S. Once you load a library into your project, the project has a static copy of the library block you're using, so any later change to the library won't break your project. So it's not a dependency in the sense that loading a JS or Python library would be.